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PREFACE 

An  overview  of  the  Graphical   Remote  Access   Support  System 
(GRASS)    is   given  in    [l].      Reference    [7]    describes  the  operation   of  the 
system  from  a  terminal  user's   viewpoint.      Reference    [8]  presents 
facilities   available  to  programs,   executing  under  the  remote  portion 
of  the   system,   that   communicate  with  the  local  terminals.      All  remaining 
references  provide   additional  background  information  concerning  the 
design  and  implementation  of  the   system.      Familiarity  with  the  above 
three  references   and  with  PDP-8   and   360  programming  is   assumed  in  the 
document.      The   system's   software    (and  this    discussion)    is    divided 
roughly  into  two   sections:      local   (satellite)    and  remote   subsystems. 

The  help   of  the   following  individuals  who   aided  in  the 
development   of  portions   of  the   system  is   great fully  acknowledged: 
Mr.    R.    Haskin    (PDP-8/I  terminal  handler),  Mr.   H.    Levin    (PDP-8  filing 
system),    and  Mr.    A.   Whaley   (360/75   filing  system). 
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1.   LOCAL  SUBSYSTEMS 

As  shown  in  Figure  1,  four  subsystems  plus  "user  level  programs" 
(hereafter  termed  "program  segments"  or  "segments")  comprise  the  local 
section  of  GRASS. 

The  multi terminal  monitor  (GLASP)  is  responsible  for  all 
device  interrupts,  storage  allocation,  and  scheduling.   Certain  minor 
functions  such  as  operator  console  support  and  real-time  clock  display 
are  also  performed  by  GLASP. 

The  Information  Retrieval  package  (.IR)  is  used  to  maintain 
data  on  the  local  mass  storage  medium,  currently  a  disk.   This  data 
includes:   library  file  space,  segment  storage,  and  transient  buffer  areas. 
In  addition,  a  directory  and  sorted/unsorted  block  lists  are  held  on  the 
disk.   GLASP,  GUTS,  and  the  segments  can  all  invoke  execution  of  IR. 

GUTS  is  a  large  collection  of  utility  routines  for  handling  all 
device  input/output  and  for  manipulating  data  structure  blocks.   Routines 
in  GUTS  may  be  invoked  by  program  segments,  either  directly  or  via  a 
scheduler  in  GLASP. 

Since  the  buffering  controller  (DPU)  is  currently  a  PDP-8/I 
computer,  a  program  to  perform  terminal  handling  (ACID)  is  needed.   ACID 
controls  and  interleaves  display  files  being  sent  to  the  terminals,  and 
regulates  the  flow  of  keyboard/X-Y  input  coming  from  the  terminals.   In 
addition,  a  dynamic  buffer  is  maintained  for  each  terminal  to  aid  in 
keyboard  text-line  preparation. 

System  response  to  user  input  is  controlled  by  the  segments. 
The  segments  are,  in  fact,  the  driving  force  within  GRASS.   For  example, 
keyboard  or  X-Y  (joystick)  input  from  a  terminal  is  handled  as  follows. 
ACID  notifies  GLASP  that  DPU  input  from  a  particular  terminal  is  ready. 
GLASP  examines  the  execution  status  of  the  terminal  and  of  the  segment 
associated  with  that  terminal.   When  the  status  indicates  "accept  input" 
and  "not  busy,"  then  execution  of  the  associated  segment  will  begin  at 
an  entry  point  corresponding  to  "DPU  input  received."  Other  entry  points 
exist  in  this  segment  (and  in  all  segments)  for  "timer  interrupt  received," 


"remote  (2701)  data  record  received,"  and  "operator  console  input 
received."   The  executing  segment  now  examines  the  input  and  makes 
an  appropriate  response.   This  might  involve  calling  GUTS  for  data 
structure  manipulation  or  device  input /output ,  invoking  IR,  or  any 
combination  of  such  activities .   The  segment  may  also  change  its  status , 
such  as  -what  input  will  be  acceptable  or  what  entry  points  may  be 
subsequently  used.   As  soon  as  the  response  is  completed,  the  terminal's 
status  returns  to  "not  busy"  and  new  input,  if  appropriate  according 
to  the  new  status,  will  cause  segment  execution  to  begin  again.   Hence, 
for  a  particular  application,  all  that  is  needed  is  an  appropriate 
segment.   Change  the  segment  and  obtain  a  text  editor,  a  library  inquiry 
station,  an  algebraic  manipulator,  a  graphical  compiler,  a  drawing 
program,  etc.   The  operation  of  segments  currently  available  is  described 
in  [7]. 

Figure  2  presents  the  allocation  of  GLASP,  IR,  GUTS,  and 
segments  with  the  associated  control/work  areas  in  the  satellite  computer. 
Each  terminal  is  related  to  a  console  vector  (Figure  3)  and  to  a  picture 
control  block  (Figures  k   and  5).   The  console  vector  controls  the  status 
of  the  terminal  at  any  time  and  is  the  communication  medium  between  GLASP 
and  the  segments.   The  PCB,  on  the  otherhand,  controls  the  status  of  the 
data  related  to  the  terminal  and  is  manipulated  exclusively  by  the  Data 
Structure  Management  (DSMN)  routines  in  GUTS.   The  general  format  of 
terminal  data  and  the  relationship  of  PCB  pointers  to  that-  data  is 
described  in  Figure  6.   Certain  standard  data  blocks  are  recognized  (and 
expected)  by  various  GUTS  routines  ;  these  blocks  are  presented  in  Figure  7 
through  Figure  10.   Two  additional  blocks  defined  for  use  by  the  system 
are  shown  in  Figure  11  (Mnemonic  Storage  Block)  and  Figure  12  (Menu  Block), 

IR  is  described  in  [6].   A  functional  description  of  ACID  is 
presented  in  Appendix  A.   Programs  and  procedures  for  generating  and 
loading  the  system  are  described  in  Appendix  B,  part  1.   Critical  areas 
of  the  system  itself  are  discussed  in  the  following  sections. 


1.1  General  GLASP-Segment-GUTS  Linkage 

All  code  is  permanently  resident  except  for  the  segments — 
only  one  segment  can  be  in  core  at  any  time.   All  code  is  executed  with 
the  CPU  interrupt  facility  0FF;  the  only  time  that  a  device  interrupt 
can  occur  is  when  GLASP  is  looping  in  an  idle  state  with  interrupt  0N. 

Two  types  of  GUTS  routines  are  provided:   indirectly  and 
directly  callable.   The  first  requires  use  of  a  device  (disk,  DPU,  2701, 
etc.)  for  performing  its  service.   Since  the  device  might  be  busy  servicing 
another  request,  the  segment  must  call  the  desired  routine  indirectly 
through  a  scheduler  (R0UTX)  in  GLASP.   Once  the  request  is  made,  execution 
will  not  be  resumed  in  the  segment  until  the  service  is  completed.   The 
second  group  performs  immediate  functions;  since  execution  returns 
directly  to  the  segment,  no  contention  can  arise,  so  the  segment  may  call 
these  routines  directly. 

The  above  provides  for  and  requires  that  all  segments  be 
"semi-re-entrant."  That  is,  all  temporary  storage  locations,  pointers, 
subroutine  returns,  intermediate  results,  etc.,  must  be  in  areas 
associated  with  a  particular  terminal  when  a  R0UTX  call  is  made.   Entry 
to  R0UTX  causes  control  to  be  lost,  as  far  as  the  segment  is  concerned, 
for  an  indefinite  amount  of  time.   While  awaiting  completion  of  the 
particular  service,  other  terminals  and/or  devices  may  present  input 
for  inspection  by  other  segments.   These  requests  will  of  course  be 
resolved,  resulting  in  changes  to  temporary  areas  and  to  the  segment  swap 
area.   In  fact,  when  the  original  service  is  completed,  a  fresh  copy  of 
the  requesting  segment  may  be  brought  into  the  segment  swap  area,  thus 
wiping  out  all  temporaries,  subroutine  returns,  etc.,  done  within  the 
segment  itself.   On  the  otherhand,  no  such  precaution  is  needed  for  direct 
calls,  since  control  returns  immediately  to  the  segment,  and  execution 
cannot  be  interrupted  by  a  device  (interrupt  is  0FF). 

Naturally,  due  to  the  "semi -re -entrant"  nature  of  segments,  any 
segment  can  service  any  number  of  terminals.   For  example,  if  segment  7 
was  a  text  editor,  and  terminals  2,  h>   and  5  all  wanted  to  use  it,  segment 
7  would  be  the  "associated"  segment  for  those  terminals  (loc+U  in  the 


console  vector  of  each  would  =  7)-   Unless  segment  7  was  replaced  in 
the  swap  area  "by  another  segment  due  to  a  request  from  some  other  terminal, 
all  three  terminals  (.2,  kt   and  5)  would  be  serviced  continuously,  without 
segment  7  ever  being  reloaded. 

Areas  associated  with  the  particular  terminal  are:   console 
vector  and  PCB  (and,  of  course,  the  data  blocks).   The  workspace  save 
area  (console  vector)  and  program  segment  scratch  area  (PCB)  are  in 
general  available  to  arbitrary  segments  as  intermediate  storage.   Almost 
all  GUTS  service  routines  require  some  parameters  as  input.   For  direct 
calls,  the  segment  puts  the  appropriate  parameters  into  the  service 
parameter  area  of  UTBANK  and  makes  the  call.   For  indirect  calls,  the 
parameters  must  be  placed  in  the  service  parameter  area  of  GLBANK;  the 
segment  then  calls  R0UTX.   These  GLBANK  parameters  are  automatically 
stored  by  R0UTX  in  the  service  parameter  save  area  of  the  console  vector 
(loc+Uo).   In  addition,  the  needed  return  information  is  stored  (loc+0,+l) 
as  well  as  the  number  of  the  requested  service  (loc+2).   When  the  desired 
service  is  available,  R0UTX  copies  the  stored  parameters  to  the  service 
parameter  area  in  UTBANK,  then  calls  the  service  as  indicated  (loc+2). 
The  service  routine,  when  finished,  returns  to  GLASP  (at  0PD0NE);  the 
service  is  marked  as  available  and  return  is  made  to  the  segment.   However, 
prior  to  the  return  to  the  segment,  the  service  parameters  in  the  console 
vector  are  copied  into  the  GLBANK  service  parameter  area. 

1.2  General  Data  Structuring 

All  data  related  to  a  terminal  (other  than  flags,  pointers, 
counters,  etc.,  in  the  console  vector  or  PCB)  is  located  in  blocks 
residing  in  DSBANK.   Each  block  contains  one  or  more  "entries,"  and 
pointers  are  kept  in  the  PCB  for  accessing  data  within  an  entry  within 
each  block  (c.f.  Figure  6).   In  addition,  the  address,  allocated  length, 
and  status  (  in-use/not-in-use,  in  -core  /not  -in-  core  ,  fixed/not-fixed)  of 
each  block  is  contained  in  the  PCB  (c.f.  Figure  5).   Each  terminal  can 
have  fourteen  blocks  associated  with  it:   five  system  defined  (Figures  7-10), 
five  user  defined  and  four  "work."  Of  the  work  blocks,  only  block  10  is 


generally  available  to  arbitrary  segments .   Block  11  is  used  by  GLASP 
during  redisplay  of  the  instance  block,  block  12  is  reserved  for  GLASP, 
and  block  13  is  used  for  maintaining  a  menu  of  the  user's  pictures  and 
mnemonics  (Figure  12). 

A  "picture"  is  defined  as  the  five  standard  and  five  user 
blocks,  plus  the  file  control  block  (Figure  5a)  that  describes  them. 
The  standard  blocks,  since  GLASP  and  GUTS  know  their  formats,  can  be 
automatically  displayed.   The  user  blocks  must  be  explicitly  manipulated 
by  a  segment  for  alteration  or  display,  but  can  have  any  contents 
(provided  the  block/entry  format  is  maintained).   For  example,  a  picture 
created  by  a  simulation  and  modeling  application  segment  might  use  two 
of  the  user  blocks  to  contain  text  entries.   These  text  entries  would 
describe  the  equations,  parameters,  and  variables  needed  for  the  network 
under  consideration.   Display  or  alteration  of  these  entries  would  be 
performed  only  by  the  segment  after  a  request  from  the  user.   The  network 
in  question  would  be  described  by  the  standard  blocks  (lines,  text, 
subpicture  instances,  terminals)  and  could  be  displayed  or  altered  automatically. 

A  "mnemonic"  is  defined  simply  as  a  Mnemonic  Storage  Block 
(Figure  11 )  and  is  created  from  the  standard  blocks  of  a  picture.   Only  a 
mnemonic  can  be  used  to  create  entries  in  the  instance  block  of  one 
picture  that  represent  an  instance  of  another  picture.   This  was  deemed 
necessary  in  order  that  picture  regeneration  not  overburden  the  resources 
of  the  satellite  computer.   All  pictures  and  mnemonics  (e.g.,  the  constituent 
blocks)  for  each  user  are  stored  in  IR.   Examining  or  altering  a  block  can 

Examining  or  altering  a  block  can  be  performed  only  via  the 
DSMN  routines  of  GUTS.   Assume  that  a  picture  has  already  been  associated 
with  the  terminal;  that  is,  a  picture  is  "current."   This  means  that 
the  FCB  for  the  picture  has  been  read  from  IR  and  placed  in  the  PCB . 
Also,  each  of  the  ten  blocks  used  in  the  picture  has  been  read  from  IR 
and  its  status  indicated  in  the  appropriate  PCB  control  entry.   Now,  the 
segment  calls  a  routine  in  DSMN  (the  loader)  to  ensure  that  the  desired 
block  is,  in  fact,  in  core.   The  loader  examines  the  appropriate  PCB 
control  entry:   if  the  block  is  in  core,  the  loader  sets  the  PCB  control 
pointers  (BLKNUM,  BLK0RG,  ENT0RG,  and  P0INTR) ,  marks  the  control  entry 
to  indicate  "fixed,"  and  returns  to  the  segment  via  0PD0NE.   If  the 


block  was  not  in  core,  the  loader  makes  an  attempt  to  allocate  space 
in  DSBANK.   After  space  is  obtained,  IR  can  be  called  (internally)  to 
read  in  the  block  from  an  IR  temporary  file.   Of  course,  if  space  was 
not  obtained,  the  loader  tries  to  swap-out  (e.g.  store  in  IR  under  a 
temporary  file)  as  many  unfixed  blocks  as  necessary  until  adequate  space 
is  available  for  loading  the  desired  block.   Note  that  calling  the 
loader  can  only  be  done  via  R0UTX  since  a  device  (the  disk)  may  be 
used  during  processing.   When  the  block  is  in  core,  the  loader  sets  the 
pointer  and  control  entry  as  previously  mentioned  and  returns  via  0PD0NE. 

The  segment  can  operate  on  a  successfully  loaded  block  by  calling 
other  DSMN  routines.   Most  of  these  can  be  called  directly  since  they  only 
perform  immediate  functions,  such  as  moving  the  block  pointers,  copying 
data  out  of  the  block,  or  testing  data  within  the  block.   Others  must 
be  called  via  R0UTX,  since  they  might  cause  the  block  to  be  expanded  or 
moved.   For  example,  adding  an  entry  or  inserting  data  within  an  entry 
may  cause  the  initial  allocation  for  the  block  to  be  exceeded.   In  this 
case,  the  allocation  is  automatically  increased  by  the  necessary  amount, 
but  in  order  to  obtain  enough  contiguous  core  area  for  the  expanded 
block,  DSMR  might  have  to  rearrange  DSBANK  slightly.   IR  must  be  called 
and  disk  accessing  must  be  performed,  thus  "losing  control"  for  the 
segment.   As  soon  as  the  segment  is  finished  with  the  block,  a  DSMN  routine 
is  called  to  mark  the  control  entry  to  indicate  "unfixed."   This  designation 
means  that  no  Input/Output  or  other  operations  are  being  performed  on  the 
block.   Hence,  the  DSMN  loader  may  store  the  block  in  an  IR  temporary 
if  space  is  needed  for  other  operations. 

1 .3  Console  Vector  Detail 

Primary  control  usage  of  the  console  vector  fields  is  described 
below;  other  manipulations  of  various  fields  are  documented  in  segment 
descriptions  or  GLASP  routine  descriptions  (see  later). 


Locations  +0  through  +13  are  for  GLASP  control: 

+0...+1   contain  the  segment  return  information  during  a  R0UTX  call. 

+2        contains  the  number  of  the  GUTS  service  requested  by  the 

segment  in  a  R0UTX  call.   A  zero  in  this  location  indicates 
the  terminal  (e.g.,  execution  by  the  associated  segment)  is 
"not  busy."  A  positive  number  means  a  GUTS  service  has  been 
requested  and  is  queued;  a  negative  number  (-l)  indicates 
that  a  requested  service  is  in  the  process  of  being  performed. 
Both  a  positive  or  negative  number  is  considered  to  indicate 
that  the  terminal  is  "busy." 

+3        contains  the  input  status  of  the  terminal.   Zero  indicates 
that  the  terminal  is  physically  available,  but  not  in  use; 
^000  means  that  the  terminal  is  physically  unavailable  and 
should  not  be  used.   2000  indicates  that  the  terminal  is  in 
use  (active)  but  no  device  input  is  pending.  Device  input 
pending  for  an  active  terminal  is  specified  by 
2001:2701 
2002 : operator 
200^ : DPU 
2010: timer 
Note  that  2003  (2701  and  Operator)  and  other  combinations  are 
valid  conditions. 

+k  contains  the  number  (0-37)  of  the  segment  currently  associated 

with  the  terminal.   "Zero"  is  the  logon  monitor  segment;  this 
segment  is  automatically  called  to  execution  for  a  terminal 
when  input  arrives  for  an  available  but  inactive  terminal 
(e.g.,  a  "here  is"  condition). 

+5... +12   contains  the  logon  string  identifying  the  user  at  the  terminal, 
This  is  set  only  by  segment  zero. 

+13       contains  an  internal  identifier  for  the  user  at  the  terminal. 
This  is  set  only  by  segment  zero. 


Locations  +lk   through  +17  are  for  a  timer  element  for  the  terminal 


+lk 


+15 


+16 


+17 


contains  a  negative  number  representing  the  duration  of  an 

interval.   This  location  is  incremented  every  l6ms ,  so  -lll6 

■would  represent  10  seconds.   The  timed  interval  is  expired 

when  the  count  reaches  zero  and  no  further  intervals  are 

required  (see  +l6,  +17  below). 

contains  a  zero  or  nonzero  flag.   If  zero,  expiration  of  the 

timed  interval  is  to  be  ignored.   That  is,  timer  input  is 

NOT  to  be  accepted.   Hence,  2010  would  NOT  be  set  in  +3.   If 

nonzero,  timer  input  is  to  be  accepted,  so  2010  would  be 

set  in  +3. 

contains  a  negative  number  specifying  the  number  of  intervals 

comprising  a  "timed  interval."  Whenever  +lk   reaches  zero, 

this  location  is  incremented.   If  the  result  is  not  zero,  +lU 

is  reset  from  +17  (see  below)  and  timing  continues.   If  the 

result  is  zero,  the  timed  interval  has  expired,  timing  ceases, 

and  timer  input  pending  is  set  in  +3,  if  applicable.   For 

example,  to  get  an  interval  of  35  seconds,  set  +1*4-  =  -UU7 

(5  sec),  +17  =  -lll6  (10  sec),  +16  =  -k ,  and  +15  to  nonzero. 

A  similar  result  could  be  obtained  by  setting  +lk   =  -U021 

(35  sec.),  +16  =  -1,  and  +15  to  nonzero  (+17  is  not  used). 

Timed  intervals  can  range  from  l6ms  to  about  70  hours. 

a  negative  number  to  be  copied  into  +lU  in  the  event  +l6  is 

nonzero. 


Locations  +20  through  +23   are   for  device   input   entry  addresses 


+20 
+21 
+22 
+23 


2701  entry  address  or  zero 
Operator  entry  address  or  zero 
DPU  entry  address  or  zero 
Timer  entry  address  or  zero 


Whenever  +3  indicates  input  pending,  the  GLASP  scheduler 
periodically  tests  +2  for  "not  busy."  As  soon  as  "not  busy"  is  recognized, 
the  associated  segment  (specified  in  +h)    is  loaded  and  entered  at 


the   corresponding  entry  address.      Of  course,    if  the  corresponding  entry 
address  was   zero  at  the  time  the   input  arrived,   +3  would  NOT  have  been 
set,    and  the  input  would  have  "been  flushed.      Hence,   +20  through  +23 
specify  whether  to   accept  or  ignore   the  different  possible   device   inputs. 

Locations   +2k  through  +36   are   for  filtering  terminal  X-Y  and  keyboard  input 
+2^  Screen  segment  0   flag 

+35  Screen  segment  9   flag 

The   display  area  of  each  terminal  is   separated  into  10  blocks 
(Figure   13).      Even  when  DPU  input   in  general  is  to  be   accepted 
(+22   is  nonzero),    certain   input  may  be   considered  as   spurious. 
For  example ,   the   segment  may  only  want  to   allow  the  user  to 
hit   (joystick  interrupt)    in  the  menu  area  or  return  box. 
Disabling  input   from  all   other  screen   areas   avoids   the  need  to 
load  a  program  segment  just  to   find  out   that  the  input   is 
spurious.      Hence,   if  the   flag   for  an   area  is   zero,   DPU  input 
pending  will  NOT  be  set   in  +3,   even  though  +22  is  nonzero.      If 
the   flag   for   an  area  is  nonzero,    a  hit  in  the   area  will   cause 
input  pending  to  be   set.      Moreover,   the  nonzero   flag  is   the 
entry  address   used  to  begin  segment  execution.      Thus,   the 
segment  not  only  gets  the  X-Y   input  but  immediately  "knows" 
what   screen   area  was  hit. 

+36  keyboard  input   entry   address   or  zero   (ignore).      As   above. 

Location  +37  is   for  2701  indicative   text-line  handling: 

+37  line  Y  coordinate  13^  to   170.      Certain  2701  text   records  are 

displayed  on  the  terminal  immediately.      This   location  serves 
as   a  permanent  pointer  to  the  next  available   line   on  the 
display  surface.      The  value  is   decreased  by  a  line  height 
after  each  use;   the  value  ikk   (bottom)    causes  wraparound  to 
the  value   13^1+   (top). 
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Locations  +U0  through  +h'J   are  for  service  parameters: 

+40...+U7  the  parameter  needed  for  GUTS  calls  are  saved  here  while 
the  request  is  enqueued  by  R0UTX. 

Locations  +50  through  +77  are  for  segment  usage : 

+50... +77  all  locations  are  available  to  segments;  consult  segment 

descriptions  for  use.   Exceptions  are  +50  and  +51;  consult 
the  REGEN  description  in  section  1.7- 

1.1+  Picture  Control  Block  Detail 

Primary  usage  of  PCB  fields  is  described  below.   Other 
manipulations  of  these  areas  are  outlined  in  the  GUTS  and  segment 
descriptions. 

Locations  +0  through  +57  are  for  the  File  Control  Block  (FCB): 

+0. . .+2   The  six  character  name  of  the  current  picture. 
+3        Type  character  word  for  a  picture  (^000). 
+U...+5   Zeroes  (Spares) 

Consult  the  REACT  segment  description  for  additional 
conventions  pertaining  to  use  of  +0...+5. 
+6        Zero  (reserved  for  protection  bits). 
+7        Internal  identifier  of  user  who  created  picture. 
+10... +57  control  entries  for  the  ten  constituent  blocks  of  the  picture 

Consult  Figure  5b  for  the  detail  of  a  control  entry. 

Locations  +60  through  +77  are  for  four  accessory  block  control  entries: 

+60...+63  work  block.   Available  for  use  by  any  segment.   For  example, 
the  drawing  segments  use  this  block  for  building  mnemonic 
storage  blocks,  while  the  REACT  segment  uses  this  block  for 
buffering  data  blocks  transmitted  via  the  2701. 
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+6U...+67  regeneration  block.   Used  by  the  automatic  display  regeneration 
routines  for  buffering  mnemonic  storage  blocks  during  display 
of  the  instance  block. 

+70... +73  spare  block.   Currently  available  for  general  use. 

+7^... +77  menu  block.   Contains  the  logged-on  user's  list  of  pictures 
and  mnemonics  saved  by  the  drawing  segments. 

Locations  +100  through  +117  are  control  fields: 

+100      BLKNUM.   On  exit  from  any  DSMN  routine  to  a  segment,  the 

address  of  the  control  entry  for  the  block  accessed  by  that 
routine  is  stored  here.   Conversely,  on  entry  to  any  DSMN 
routine  from  a  segment,  this  location  is  used  to  indicate 
the  "current"  block  being  investigated.   The  appropriate 
"current"  ENT0RG  and  P0INTR  for  the  block  can  be  fetched 
from  the  control  entry  described  by  BLKNUM. 

+101      lockout.   Used  by  the  DSMR  loader  to  indicate  that  no 

lockout  (0)  or  lockout (-1)  occurred  while  attempting  to 

allocate  space  for  a  block.   This  location  is  set  only  by 

the  loader,  so  all  subsequently  invoked  routines  (GUTS  and/or 

segments)  can  test  it. 

+102.. .+103 

spares . 

+101+ .  .  .+105 

previous  ENT0RG  and  previous  P0INTR.   DSMN  routines  that 

alter  ENT0RG  or  P0INTR  first  store  the  old  values  here. 

This  is  sometimes  useful  while  searching  down  the  entries  in 

a  block. 

+106      instance  block  regen.   The  automatic  display  regeneration 

routines  save  the  number  of  the  control  entry  that  points  to 
the  instance  block  being  redisplayed  in  this  location. 

+107      spare. 

+110      MNM0D.   One  of  the  DSMN  routines  that  alters  P0INTR  always 
adds  in  the  contents  of  this  location.   This  is  very  useful 
for  scanning  down  the  entries  of  a  block  and  looking  at  a 
particular  data  word.   The  normal  value  of  MNM0D  is  zero. 
It  should  always  be  reset  to  zero  after  use  with  another  value. 


12 


+111      spare. 

+112... +113 

Y,  X  coordinates.   The  DPU  input  filtering  routine  always 

stores  the  Y,  X  coordinates  here  for  accepted  joystick 

input  from  the  terminal . 

+11U...+115 

reference  center.   The  Y,  X  coordinates  of  the  screen  area 

reference  center  are  stored  in  these  locations.   Several 

DPU  routines  utilize  these.   The  normal  values  are  1000,  1000. 

+116...+117 

spares . 

+120. ..+177 

work  area  (PCW0RK).   Generally  available  for  segments.   Often 

used  to  buffer  2701  indicative  text-lines  before  display  at 

the  terminal  or  to  buffer  text  lines  from  the  terminal  before 

transmission  over  the  2701.   Other  usage  indicated  in  the 

segment  descriptions. 

1.5  GLASP  Routines 


The  monitor  is  composed  of  two  sets  of  routines:   system 
functional  and  segment  functional.   The  former  handle  all  internal 
control  operations  needed  by  the  system  and  are  activated  either  by 
device  interrupts  or  by  entry  from  GUTS  routines  or  segments .   The 
latter  perform  some  utility  function  upon  entry  from  a  segment. 

System: 

Interrupt  handler  (INTHND):   trap  all  device  interrupts,  link  to  GUTS 

device  routines,  and  link  to  input  routines. 
2701  input  (FR2701) :   recognize  remote  input,  set  2001  pending. 
Operator  input(0PKB):   recognize  operator  command  input,  set  2002  pending 
DPU  input  (DPUINR):   recognize  DPU  input,  set  200U  pending. 
Timer  input  (CLKQR):   recognize  timer  input,  set  2010  pending. 
GUTS  service  requests  (R0UTX):   enqueue  segment  service  requests,  set 

request  pending. 
Scheduler  (TSTQUE) :   text  input  pending  and  service  request  pending  for 

each  terminal,  attempt  to  start  segment  if  pending  found. 
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Idler  (WAIT):   test  system  priority  flags,  call  scheduler,  await  device 

interrupts . 
GUTS  service  completion  (0PD0NE):   restart  segment  execution  according 

to  console  vector  data. 
Segment  completion  (RELESE )  :   mark  terminal  "not  "busy,"  safety  unfix 

of  all  data  blocks,  call  idler. 


Segment : 

Load  new  segment    (XCTL) :      change   segment   associated  with  terminal, 

loads  new  segment   and  begins   execution. 
2701  indicative  lines    (GSMSGA):      displays   2701  text-line  message   on  terminal, 
Terminal   input   filtering   (DPUDIN):      helps   filtering  spurious  terminal  input. 
Standard  block   display   (GREGEN):      automatically  regenerates   display   at 

terminal  for  five   standard  system  "blocks . 
Text  messages    (GREGPl) :      helps   set  messages   into   display   files   for 

output   to  terminal . 
SVPUT:      pass   a  parameter  to   a  particular  service  parameter  location 

in  UTBANK. 
FREDPU:      clear  DPU  flags   and  blank   first  part  of  input  buffer. 

This    call  MUST  ALWAYS  be  made  as   soon  as  the   segment  is 

done  examining  the   DPU  input . 
RETIME:      reset  timer  element   for  ten  minutes. 
FREDIM:      call   FREDPU  and  RETIME. 

RLV1,RLV2,RLV3:      call  XCTL  for  return  to  a  previous   segment. 
M0VEDT:      arbitrary  movement  of  data  between   any  pair  of  banks. 


SADCV 

SSTCV 

SADPC 

SSTPC 

ST0P 

STWK 

LDWK 


add  to  the  ACC  the  word  at  +n  in  the  console  vector. 

store  the  ACC  at  +n  in  the  console  vector. 

add  to  the  ACC  the  word  at  +n  in  the  PCB. 

store  the  ACC  at  +n  in  the  PCB. 
reset  the  console  vector  beginning  at  +lk   through  +37- 
reset  the  console  vector  beginning  at  +50  through  +77* 
reset  the  page  0  work  area  (loc  150-177)  from  the  workspace 
save  area  in  the  console  vector  (+50  through  +77) • 
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SVPRLD:      reset  the  page  0   service  parameter  area  in  GLBANK  or  UTBANK 

from  the  console  vector   (+1+0  through  +1+7). 
SVPRSV:      reset   the   console  vector  service  parameter  area   (+k0  through 

+1*7)    from  the  page   0  service  parameter  area  of  GLBANK  or  UTBANK. 
T0LAC:      test  a  terminal   for   active/online/offline   status. 
GLINE:      calculate   a  line  number  from  a  menu  Y  coordinate. 

More   detailed  descriptions   of  the  GLASP  routines   are 
presented  in  Appendix  C. 

1.6     GUTS  Service   Routines 

The   routines   comprising  GUTS   are   divided  into  numbered  groups 
according  to  function  and  to   system  resource  monopolized: 

1.  Data  Structure  Management    (DSMN)    Core 

2.  Information  Retrieval   (IR)    Disk 

3.  2701  Send  (T027O1)   2701  out-channel 
k.  2701  Receive    (F027O1)   2701  in-channel 

5.  Display  Processing   (DPU)   DPU  channel   and  buffer 

6.  Hardcopy  Printing   (INK)   Inktronic  printer 

The   request  number  specified  in  a  R0UTX  call  is   the  group  number.      Each 
service  group  is   associated  with  a  flag  word  and  an  entry  address.     When 
the   flag  is   zero,   the   service   is  not  busy   (idle);  hence,    another 
segment  request   for  its   function   can  be   accepted.      The  terminal's   console 
vector  address   is   stored  into  the   flag  word   (the  service   is  now  busy; 
subsequent  requests   from  other  terminals  will  be   enqueued)    and  execution 
is  begun   at  the   service's   entry  address   in  UTBANK.      When  the  service   is 
completed,   0PD0NE  will  replace  the   console  vector  address   in  the   flag  word 
with   zero,   setting  the   service   "not  busy." 


DSMN: 

R0UTX  entry  (MNNTRE):   SVPRM1  specifies  routine  to  be  used.   On  return 
to  R0UTX,  ACC  stored  in  console  vector  SUPRM8  location  as 
return  code.   Before  the  indicated  routine  is  invoked,  the 


15 


BLKNUM  field  in  the  PCB  is  used  to  reset  the  current  block: 
ENT0RG,  P0INTR,  and  BLK0RG  are  set  from  the  indicated  PCB 
entry.   After  the  indicated  routine  terminates,  the  current 
values  of  ENT0RG,  P0INTR,  and  BLKNUM  are  saved  in  the 
appropriate  PCB  area.   This  provides  a  means  for  passing  the 
current  block  from  one  routine  to  the  next ,  even  when  the 
routines  must  be  invoked  with  R0UTX. 

Direct  call  entry  (MNDPC)  :   SVPRM1  specifies  routine  to  be  used.   ACC 
contents  passed  to  routine  and  final  ACC  contents  returned 
to  calling  program.   Current  block  pointers  set  and  saved  as 
in  MNNTRE. 

Load  data  structure  block  (MNL0DR) :   make  specified  block  ready  for 

manipulation.   If  not  in  core,  bring  it  in  from  IR;  initialize 
pointers  to  the  first  entry  in  the  block  and  set  status 
in -core /fixed.   This  block  is  now  considered  as  the  "current 
block"  being  manipulated.   (Called  via  R0UTX) . 

Set  status  "Unfixed"  (MNUNF) :   current  manipulation  of  the  specified 

block  is  at  an  end;  mark  it  as  available  to  be  "swapped  out" 
(Called  via  direct). 

Delete  a  block  (MNDEB):   if  the  specified  block  is  in  use,  mark  it  as 

not  in  use;  free  any  core  it  may  occupy;  and  delete  its  storage 
temporary  from  IR  if  one  exists.   If  the  current  picture  is 
subsequently  stored  in  IR,  this  block  will  NOT  be  part  of  the 
picture.   (R0UTX). 

Start  a  block  (MNIBA) :   essentially  do  an  MNDEB  to  clean  up, then  set  the 
initial  size  of  the  block  (initial  allocation)  and  call  MNL0DR. 
Core  will  be  allocated,  and  the  block  is  marked  in-use,  in- 
core,  fixed,  but  NOT  initialized.   This  block  is  now  the  current 
block.   If  the  current  picture  is  subsequently  stored  in  IR, 
this  block  will  NOT  be  part  of  the  picture.   (R0UTX). 

Set  first  data  (MNIBD) :   set  the  initial  block  data  desired  into  the 
current  block;  the  block  is  marked  initialized.   A  previous 
MNIBA  call  is  assumed;  all  other  DSMN  routines  can  NOW  be  called 
to  manipulate  the  block.   Unless  an  MNDEB  call  is  made,  this 
block  will  be  part  of  the  picture  if  subsequently  saved  in 
IR.   (Direct). 
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Swap  block  out    (MNST0R) :      explicitly  store   specified  block  in  an  IR 
temporary,   thus   freeing  whatever  core   it  is   occupying. 
This   call  is  ROT  usually  needed,   since  MNL0DR  automatically 
swaps   out  unfixed  blocks   as  the  need  arises.    (R0UTX). 

Save   status    (MNBSV) :      the  pointers   associated  with  the   current  block 

are   saved  in  the  appropriate   PCB  entry.      See  MNBRS   and  MNBTB. 
Note  that  the  block  remains  marked  as   fixed  and  in-core.      (Direct) 

Reset  status    (MNBRS):      the  pointers   stored  in  the  PCB  entry  of  the 

specified  block  are  used  to   reset   that  block  as  the  current  block. 
The   specified  block  is   assumed  to  be   fixed  and  in-core    (e.g.,   a 
call  to  MNL0DR,   some   arbitrary  DSMN  calls,   and  an  MNBSV  call 
all  preceded  this    call).      See  MNBSV  and  MNBTB.      (Direct). 

Block-to-block  data  transfer   (MNBTB):      data  or  entire  block  entries   are 
copied,   inserted,   or  replaced  from  one  block  to   another.      The 
FR0M  location  is   specified  by  the  pointers   in  the  PCB  entry  of 
the   specified  block   (e.g.    saved  by  MNBSV).      The  T0  location  is 
specified  by  the  pointers   of  the   current  block.      After  some 
set  up,  MNBTB  calls  the  DSMN  routine   specified,   usually 
MNRPL,   to  actually  perform  the  operation.      See  MNBSV,   MNBRS, 
and  MNRPL.      (R0UTX). 

Next  entry   (MNNXTE) :     move  the  pointers   of  the   current  block  to  the  next 
entry  in  the  block.      The   current  values   of  ENT0RG  and  P0INTR 
are    first  stored  in  SHDERG  and  SHDPTR  to   allow  one-level  back 
tracking.      Then  ENT0RG  is  updated  to  the  address   of  the  next 
sequential  entry,  while   P0INTR  is   updated  to  the   address   of 
the   first   data  word  in   that  entry  plus   a  specified  displacement 
(MNM0D).      See  MNFPR.      (Direct). 

Move  pointer   (MNFPR) :      the  P0INTR  of  the   current  block  is   reset  within 

the   current  entry  by  the  positive   or  negative   amount  in  the  ACC. 
See  MNFPRA.       (Direct). 

Reset  pointer  current   (MNFPRA) :      the  P0INTR  of  the   current  block  is   reset 
from  its   current  position  in  the  entry  to  the  beginning  of  the 
entry,   as   in  MNNXTE.      See  MNNXTE.      (Direct). 


IT 

Reset  entry  (MNPERG) :   both  ENT0RG  and  P0INTR  of  the  current  block 

are  reset  as  in  MNNXTE ,  but  to  the  specified  n-th  entry.   (Direct). 
Reset  and  locate  (MFPRT) :  both  ENT0RG  and  P0INTR  of  the  current  block 

are  reset  as  in  MMXTE,  but  to  the  first  entry  in  the  block. 

In  addition,  the  address  of  the  block  is  returned  in  the  ACC. 

This  address  is  ONLY  to  be  used  when  calling  IR  or  2701  services ; 

explicit  manipulation  of  blocks  is  not  allowed.   (Direct). 
Load  word  (MPL0D,  MNEL0D,  MNBL0D)  :   the  word  in  the  current  block 

pointed  to  by  P0INTR,  ENT0RG,  or  BLK0RG,  respectively,  is 

returned  in  the  ACC.   (Direct). 
Store  word  (MNPSET,  MNESET,  MNBSET):   the  ACC  is  stored  at  the  word  in 

the  current  block  pointed  to  by  P0INTR,  ENT0RG,  or  BLK0RG, 

respectively.   (Direct). 
Replace  data  (MNRPL) :   the  specified  data  replaces  data  at  the  current 

position  indicated  by  ENT0RG  and  P0INTR  in  the  current  block. 

Depending  on  parameters  supplied,  entire  entries  can  be 

replaced,  inserted,  or  deleted,  and  data  within  an  entry  can 

be  replaced,  inserted  or  deleted.   (R0UTX). 
Insert  new  entry  (MNNEN):   the  specified  data  is  inserted  into  the  current 

block  before  the  current  entry  indicated  by  ENT0RG  as  a  new 

entry.   After  some  set  up,  MNRPL  is  called  for  the  actual 

operation.   (R0UTX). 
Inset  new  entry  end  (MNNNE):   exactly  as  MNNEN,  but  new  entry  is  at  the 

end  of  the  current  block.   (R0UTX). 
Insert  new  data  (MNINE):   exactly  as  MNRPL,  but  allows  data  to  be  inserted 

at  the  end  of  the  current  entry.   (R0UTX). 
Insert  new  data  end  (MILE)  :   exactly  as  MINE,  but  allows  data  to  be 

inserted  at  the  end  of  the  last  entry  of  the  current  block.   (R0UTX) 
Extract  (MEXTC):   the  specified  amount  of  data  is  extracted  (copied)  to 

the  specified  location  from  the  current  P0INTR  location  of  the 

current  block.   (Direct). 
Build  mnemonic  (MNMNEM) :   a  Mnemonic  Storage  Block  is  constructed  in 

block  12  from  the  standard  blocks  of  the  current  picture.   (R0UTX). 


18 


Integrate  mnemonic  (MNMNIN):   the  Mnemonic  Storage  Block  currently  in 
block  12  is  integrated  into  the  instance  block  (block  2)  and 
terminal  block  (block  k)   of  the  current  picture.   (R0UTX). 

Complete  remote  block  transmission  (MN2TB) :  set  up  the  current  block 
to  receive  a  2701  input  record.  See  F02701  and  Appendix  B. 
(Direct ) . 

The  above  routines,  along  with  a  large  number  of  other  less 
often  used  routines,  are  described  in  greater  detail  in  Appendix  D,  Part  1. 

IR: 

R0UTX  entry  (IRREQ):   initiate  an  operation  in  the  local  filing  system. 
This  is  the  only  call  available  (or  necessary)  for  segments 
desiring  direct  access  to  the  filing  package.   The  parameters 
needed  are: 

SVPRM1  =  function 

SVPRM2  =  file  type 

SVPRM3-5  =  6    character   file  name 

SVPRM6  =   core  location  of  data 

SVPRM7  =   file  length    (write)   or  available   core    (read) 

SVPRM8  =  owner's   ID   (protection) 

The   functions   available   include: 

READ  into   DSBANK   (6l00)    or   into  WKBANK   (6000) 
WRITE   from  DSBANK    (2100)    or  WKBANK   (2000) 
DELETE    (2200) 

A  file  is   uniquely  identified  by  its  name     plus  the  owner's   ID 
plus   its  type.      Note  that   IR  directory  blocks   are   accessed  by 
hash  coding  the  ID  and  the   file  name  ;   the  type   is  purposely 
left  out   of  the  hash  procedure.      This   ensures  that  the  directory 
entries   for  all  files  that  differ  only  by  type  will  be   located 
close  together,   thus   speeding  retrieval  of  all  such   "related" 
files.      The   following   conventions  have  been  established  for 
storing  pictures    (l),   mnemonics    (2),  block  temporaries    (3)» 
and  menu  blocks    (U),   in   IR: 
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NAME 


ID 


(1)  six  user-specified  from  console 
characters  vector 

(2)  six  user-specified  from  console 
characters  vector 

(3)  0,  PCB  control 
entry,   0   address  0 

(1+)      0,0,   user's   ID  0 


TYPE 
l+000(8)-l+0l2(8)* 

l+ol+o(8)-Uol+7(8)** 


1+001(8) -1+017(8)' 
hoi6+ 


All  other  name/type  combinations  can  be  used  by  segments  as 
desired,  except  for  types  1+020-1+037  and  1+050-1+077  which  are 
reserved  for  future   system  use. 

Note,    for  example,   that  the  picture   DI0DE  composed  of  blocks   0, 
1,   2,    1+,    5,   and  6  with  mnemonics   DI0DE.O   and  DI0DE.1  will  be 
stored  in  nine   related  IE  files.      All  nine  will  have  the  same 
six  character  names   and  user  ID,  but  the  types  will  be   1+000, 
1+0001,    1+002,   1+003,    1+005,   1+006,    1+007,    UOUO,   and  UoUl.      Note, 
also,   that   to  read  or  write  the   information  contained  in  a  data 
structure  block,   the  block  must  have  been   loaded   (MNL0DR  or 
MNIBA)   and  its   address   obtained  via  MNFPRT. 

A  complete   description  of  the  operation  of  IR  is  presented 


m 


[6] 


*     The   last  two   digits   correspond  to  the  respective  block  number,  with 
00=file   control  block,   01=block  0,...,   12=block  9. 

**  The   last   digit   corresponds  to   the  mnemonic   designation,   e.g.,   RESIST. 6 
implies   type   h0h6 . 


Same   as   for  *,  but   file   control  block  is  never  stored  in   a  temporary; 
1+013-1+106  are   for  work  blocks   10  to   13    (1+017  is   currently  unused  since 
there   is   no  block   designated  ll+). 
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T02TO1: 

R0UTX  entry   (T027O1) :      transmit   data  to  the   360/75.      The  parameters 
needed  are  : 
SVPRM1  =   record  type 
SVPRM2  =   data  bank 
SVPRM3  =   data  address 

SVPRM4  =   data  length  minus   1   (0-1+095  =  I-U096) 
Transmission   can  only  take  place  when  the  2701  is  not  "busy, 
e.g.,    a  read  cannot  be   in  progress.      Note   that  to  send  the 
information   contained  in   a  data  structure  block,   the  block  must 
have  been  loaded   (MNL0DR)    and  its   address   obtained  via  MNFPRT. 
Record  types    for  data  structure  blocks   are   identical   to  IR 
file  types,   e.g.    UOOO-UOIT   and  h0k0-k0krJ .      Types   7770-7777   are 
reserved  for  monitor-to-monitor  internal   commands ;   type  0 
always  means   the   record  is   a  simple   text-line.      Type   1  is  used 
by  some   segments    (REACT,   etc.)    to   indicate  joystick  X,   Y  data. 
All  other  types,   except   U020-U037   and  kO^O-hOTl ,   are   available 
for  arbitrary  segment   use.      A  good  example  is  provided  by 
REACT;   see    section   1.7,    REACT. 

The   record  actually  transmitted  is: 

+0  +1  +2  +3        ...  +n 

00N0        TYPE        LEN         |«-        DATA       ->| 

where  N  is   the  terminal  number   and  DATA  is  the  information 
beginning   at  the  location   specified  by  SVPRM3.      If  n  >   128 
(>125    data  words),   two   records   are   actually  sent.      The   first 
contains   the   terminal  number,   record  type,   total  length,    and 
the  first   125   data  words;   the  second  record  contains   just  the 
remaining   data  words.      This  procedure   facilitates  buffering  in 
the   360/75.      Note  that  the  360/75   uses  this  two-part 
convention   for  sending  records   to  the  PDP-8. 
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K02TO1 : 

R0UTX  entry  (F027O1) :   complete  a  record  transmission  from  360/75. 
Whenever  a  send  to  the  360/75  is  not  in  progress,  a  read- 
ready  status  is  maintained  in  the  PDP-8.   Due  to  the  two-part 
record  convention  (see  T027O1) ,  the  PDP-8  must  remember 
whether  the  input  data  is  the  second  part  of  a  record  or  the 
first  part  of  a  new  record.   In  the  first  case,  the  data  is 
only  read  into  the  PDP-8  after  an  appropriate  segment  call  to 
F027O1;  before  making  the  call,  the  segment  must  provide  a 
buffer  for  the  entire  record  and  must  move  the  first  part  of 
the  record  into  the  buffer.   The  F027O1  call  not  only  completes 
the  read  operation,  but  also  allows  the  system  to  reset  in 
case  the  first  part  of  a  new  record  comes  along.   In  addition, 
a  check  is  made  to  see  if  a  T027O1  call  became  pending  while  the 
read  was  in  progress;  if  it  did,  a  write  operation  is  started. 

In  the  second  case,  when  the  first  part  of  a  new  record  is 
expected,  the  system  automatically  reads  the  data  into  a  128 
word  buffer.   The  terminal  to  be  notified  (via  GLASP  routine 
FR2701)  can  be  ascertained  from  the  terminal  number  in  the  first 
word  of  the  record.   After  the  proper  console  vector  is  marked, 
no  further  action  is  taken  until  the  segment  makes  the  F027O1 
call.   Note  that  this  is  true  even  if  no  second  part  is  expected. 
System  processing  of  further  2701  input  must  wait  until  the 
appropriate  segment  examines  the  record  in  the  system  buffer, 
takes  action,  and  notifies  the  system  that  the  buffer  is  now 
"clear"  with  the  F027O1  call. 

When  the  segment's  execution  begins  at  its  "remote  (2701)  data 
record  received"  entry  point,  the  following  information  is 
available  in  UTBANK: 

F2701C  is  the  start  of  the  128  word  buffer  containing  the  first 

part  of  the  record. 
F2701T  (F2701C+1)  contains  the  record  type  (all  types 

identical  to  T027O1  usage). 
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F2T01L   (F2T01C+2)    contains  the   data  length  -1    (as   in  T02TO1). 

F2T01D   (F2T01C+3)    is   the   first   data  word. 

I2701P  is    a  flag  containing  a  1   (second  part  expected)    or 

a  -1   (no  second  part   since  F2T01L  <   128   (<125   data  -words)). 

From  this   information,   the  segment   should  be   able  to   decide 
how  big  the  entire   record  is   and  what  should  be   done  with  it. 
Even  if  no   second  part  is   expected,   the  F027O1  call  must  be 
made   so  that   the  system  realizes  that     tie  buffer  is   clear  and 
2701  input   or   output  processing   can  begin  again.      The  system 
will  not   try  to   read  a  non-existent  second  part  since  the 
I2701P  flag  is    checked  by  the  F027O1  routine.      The  parameters 
for   F027O1   are: 

SVPRM2   =   data  bank 
SVPEM3  =   data  address 

SVPRM^  =   data  length   (0  means   "use  preset   remainder";   see 
example  below) 

A  typical   use   of  the  2701  input   facility  would  be  the  transmission 
of  a  data  structure  block  from  the   360/75  to   replace   a  block  in 
the   current  picture   of  the   receiving  terminal.      The   first  part 
of  the  record  is   sent  by  the  3^0/75   an<3-  automatically  read  into 
the   standard  buffer  in  the  PDP-8.      The   appropriate   console 
vector  is  marked,   and  the  associated  segment  begins   execution. 
The   segment  uses   F2701L  to  calculate   the  total  number  of  core 
pages   required  by  the  block;  MNIBA  is   then   called  to  establish 
a  block  of  this   size.      MN2TB  is    called  next;   this   routine  moves 
the  data  from  the   standard  buffer  into  the  beginning  of  the 
new  block.      It  then   calculates   and  returns   the  address  within 
the  block  at  which  the   second  part   of  the   record,   if  it   exists, 
would  start.      In   addition,   it    calculates   and  sets  the  remaining 
record  length   for  the  second  part   ("preset   remainder").      The 
segment   sets   SvPRM2=DSBANK,SvPEMU=0 ,    and  SVPRM3=address- 
returned-by-MN2TB  ;   and  F027O1  is    called.      If  the  second  part 
exists,   the  read  operation  transfers   the  data  directly  into 
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the  receiving  block.   Then  the  system  resets  for  the  next 
record.   If  the  second  part  does  not  exist,  just  the  reset 
occurs.   Note  that  in  this  example,  the  segment  did  not  ever 
check  whether  the  record  was  composed  of  one  or  two  parts, 
since  its  actions  in  either  event  would  have  been  the  same. 

DPU: 

R0UTX  entry  (DPUENQ) :   serialize  the  use  of  the  buffering  controller 
(DPU).   The  requesting  terminal  (segment)  now  has  exclusive 
control  of  the  terminal  output  buffer  and  the  buffer  is 
initialized.   The  segment  makes  direct  calls  to  other  DPU 
routines  to  construct  a  display  file  in  the  buffer.   When  the 
display  file  is  finished  (marked  complete),  it  will  be  sent 
to  ACID  for  transmission  to  the  specified  terminal.   When  the 
buffer  has  been  emptied  by  ACID,  control  is  returned  to  the 
segment  via  0PD0NE.   See  Appendix  A.   If  SVPRM8  is  not  zero, 
its  contents  are  assumed  to  be  an  immediate  command,  such  as 
"Erase"  or  "Disable."   This  one-word  display  file  is  sent 
immediately  to  ACID,  the  DPU  is  released,  and  control  returns 
to  the  segment  via  0PD0NE.   If  SVPRM8  is  zero,  control  returns 
directly  to  the  segment  so  direct  calls  can  commence.   The 
output  buffer  is  U000(8)  words,  long  enough  to  hold  the  display 
file  for  an  entire  screen  of  text.   If  during  direct  calls  this 
buffer  is  exceeded,  further  calls  are  ignored  (e.g.,  no  data  is 
placed  in  the  buffer)  until  the  file  is  marked  complete  by  the 
segment.   The  truncated  file  is  then  sent  to  ACID. 

Direct  call  entry  (DPUPDC):   the  ACC  specifies  the  routine  to  be  used. 
ENT0RG  and  P0INTR  are  reset  from  the  PCB  entry  indicated  by 
BLKNUM  (e.g.  ,  current  block)  as  in  DSMN  processing  for  those 
DPU  routines  that  need  to  examine  the  current  block.   However, 
the  final  values  of  ENT0RG  and  P0INTR  are  NOT  returned  to  the  PCB, 

Initial  text-line  and  complete  (DPUA):   the  buffer  is  initialized,  the 

specified  data  is  inserted  as  a  single  text  line  at  a  specified 
Y,  X  and  the  file  is  marked  complete.   Control  is  returned  to 
the  segment  when  the  buffer  is  empty  (E). 
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Initial  vector  and  complete    (DPUB):      as   in  DPUA,  but  the  display  file 

is   a  line  "between  two  Y,   X  pairs. 
Initial  file  and  complete    (DPUC):      as   in  DPUA,  but  the  display   file 

is   any  arbitrary   data  supplied  by  the  segment.      Also,   if  the 

data  length  specified  is    zero,   the  buffer  is     not   initialized. 

Rather,   the   current   file  under  construction  is  marked  complete; 

control  then  returns  to  the  segment   as   in  DPUA. 
Position  beam  point    (DPUDP):      a  point   command  moving  the  beam  to  the 

specified  Y,   X  is   added  to  the  current   display  file.      The 

point  may  be  specified  as  visible   or  blanked   (not   visible). 

Control  returns   immediately  to  the  segment    (i). 
Position  beam  vector   (DPUDV,    DPUDl):      a  vector   command  moving  the  beam 

between   a  pair  of  specified  Y,   X  points   is   added  to   the  current 

display   file.      If  the  beam  is   specified  as   visible,   a  line 

results.      (I) . 
Text-line    (DPUE):      the   specified  data  is   added  as   a  single   text   line   at 

a  specified  Y,   X  to  the   current   display  file.      (i). 
Add  small   (DPUF) :      up  to   five   data  words   are   added  to  the  current 

display  file   from  the   SVPRMU-8.      (i). 
Add  arbitrary   (DPUG):      arbitrary  length   data  as   specified  is      added  to 

the   current   display  file.      (i). 
Add  vectors    (DPUH):      arbitrary  length   data   consisting  of  vector  commands 

is   added  to   the    current   display   file,  but   an  enter-vector-mode 

command  is   inserted  first  and  an  exit-mode   sequence   is   added  at 

the  end.      (I ) . 
Add  text  entry    (DPUI):      all   text-lines   in   the   current  block  entry  pointed 

to  by  ENT0RG  and  P0INTR  are   formatted  for  display  and  added  to 

the  current   display   file.      (I). 
Add  text  block   (DPUJ):      all  text-lines   in  the   current  block  entry  pointed 

to  by  ENT0RG  and  P0INTR  and  all  text   from  all  remaining  entries 

in  the  current  block  are   formatted  for  display  and  added  to  the 

current   display   file.      (I). 
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Pass  text  line  (DPUK,  DPUKA,  DPUKB) :   transmit  specified  text  line  to 

DPU  for  placement  in  terminal's  line  creation  buffer.   (E). 
Add  terminal  entry  (DPULY):   format  and  add  specified  terminal  entry  to 

current  display  file.   (i). 
Add  terminal  "block  (DPUL)  :   format  all  terminals  and  terminal  connections 

in  current  block  (terminal  block  h)    and  add  to  current 

display  file.   (i) . 
Add  line  block  (DPUNL):   format  all  point  groups  in  current  block  (line 

block  0)  and  add  as  visible  vector  commands  to  current  display 

file.   (I). 
Add  mnemonic  instance  (DPUM) :   format  lines  and  text,  or  parameters 

model  list,  or  lines  only,  or  text  only  as  specified  from 

current  block  (mnemonic  storage  block  12  or  13)  and  add  to 

current  display  file.   (I). 

A  complete  list  of  the  DPU  routines  is  presented 
in  Appendix  D,  Part  2. 

INK: 

R0UTX  entry  (INKENQ):   serialize  the  use  of  the  local  hardcopy  printing 
device.   The  requesting  terminal  (segment)  now  has 
exclusive  control  of  the  printer  output  buffer  and  the  buffer 
is  initialized.   Control  is  immediately  returned  to  the 
segment ;  the  segment  makes  direct  calls  to  INKLP  for  each 
complete  line  (80  characters  or  less)  to  be  printed. 

Print  a  line  or  complete  ( INKLP ):   the  specified  data,  a  packed  character 
string,  is  unpacked  into  the  print  buffer,  and  printing  begins. 
Control  is  not  returned  to  the  segment  until  the  line  is 
finished.   If  the  data  length  is  specified  as  being  zero,  the 
service  is  marked  not  busy  (as  would  be  done  by  0PD0NE)  and 
control  immediately  returns  to  the  segment. 

SVPEM5  =  character  count  (<_  0  >_  80) 
SVPRM6  =  data  address 
SVPRM7  =  data  bank 
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1.7  Program  Segment  Descriptions 

GLASP  has  provision  for  32  concurrently  available  segments;  the 
normal  (typical)  allocation  of  "system"  and  "application"  segments  is 
shown  in  Figure  lU.   The  minimum  number  of  system  segments  is  three  (CALR, 
DEX1 ,  and  PSIR) ;  if  the  number  of  valid  users  is  fairly  large  (>256)  and 
if  special  functions  are  added  to  IR,  as  many  as  three  more  segments  may 
be  needed  (DEX2,  DEX3 ,  and  SPIR) .   Three  segments  containing  utility 
functions  (GUT1,  GUT2 ,  and  GUT3)  are  available;  these  utilities  may  be 
called  by  any  segment.   A  very  powerful  generalized  drawing  package  is 
provided  (GND1,  GND2 ,  and  GND3)  which  requires  still  another  three 
segments.   Hence,  the  number  of  truly  free  segments  for  application  use 
is  usually  20.   Supporting  the  Simulation  and  Modeling  application 
(GSAM)  required  less  than  one-half  of  a  single  segment;  a  shortage  of 
application  space  seems  highly  unlikely.   Moreover,  whenever  the  system 
is  loaded,  any  group  of  20  application  segments  may  be  loaded. 

The  general  activity,  and  some  of  the  possible  events,  that 
may  take  place  during  execution  of  the  segment  GSAM  will  be  briefly 
described  since  this  segment  exemplifies  typical  applications  support. 
On  entry  from  CALR  (the  user  picked  GSAM  from  the  menu),  GSAM  uses  routine 
ST0P  to  reset  the  control  area  of  the  console  vector;  this  includes  the 
timer  element,  device  input  addresses,  and  the  screen  segment  filter 
words.   GSAM  then  enqueues  the  DPU  with  a  R0UTX  call  and  uses  GREGP1  as 
well  as  DPU  direct  call  routines  to  build  a  display  file.   The  new  display, 
containing  some  messages  and  a  list  of  three  mode  options  in  the  menu  area, 
is  sent  to  the  terminal  with  a  DPUC  call.   When  the  DPU  output  buffer  in  the 
PDP-8  is  empty,  the  DPU  service  is  marked  "not  busy"  and  control  is  returned 
to  GSAM  via  0PD0NE.   GSAM  returns  to  GLASP  via  RELESE  to  await  terminal 
input,  specifically  a  hit  on  one  of  the  options  in  the  menu. 

Several  user  hits  in  the  draw,  prompt,  and  light  button  areas 
as  well  as  a  keyboard  text-line  are  ignored  by  GLASP;  the  filter  words 
in  the  console  vector,  as  set  by  ST0P,  indicate  these  inputs  are  considered 
invalid.   Meanwhile,  an  indicative  text  message  (type=0)  arrives  over 
the  2701;  this  input  is  to  be  accepted.   GSAM  calls  routine  GLMSGA  to 
transfer  the  line  to  the  terminal  at  the  top  of  the  draw  area.   Finally, 
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the  user  hits  in  the  menu  area;  GLASP  stores  the  Y,  X  coordinates  in  the 
PCB  (via  PICSEG).   BPUDIN  is  entered  and  transfers  control  to  the  entry 
in  GSAM  specified  by  the  menu  area  filter  word.   Since  only  the  Y 
coordinate  needs  to  be  investigated  and  it  is  already  in  the  PCB,  an 
immediate  call  to  FREDTM  Is  made.   The  DPU  input  mechanism  is  released 
for  more  terminal  input,  and  the  timer  for  this  terminal  is  reset  to 
ten  minutes . 

The  menu  line  hit  was  C0NSTR,  so  GSAM  puts  return  data  into 
the  console  vector  level  two  return  and  uses  XCTL  to  call  the 
generalized  drawing  package,  GND1.   The  user  interacts  in  a  similar 
manner  with  GND1 :   building  a  picture,  calling  IR,  directly  invoking 
REACT,  etc.   Finally,  the  user  returns  from  GND1  to  GSAM,  and  GSAM 
re-initializes  the  console  vector  and  display  as  it  did  on  the  first 
entry  from  CALR. 

Now  the  user  hits  menu  line  two:   SPECFY.   GSAM  changes  the 
console  vector  control  area  and  puts  up  a  new  list  of  options.   The 
sixth  option  is  chosen,  Indicating  that  the  user  wants  to  add  some 
equations  to  the  picture.   This  means  text  editing  in  entry  one  of  block 
6.   MNL0DR  is  called  via  R0UTX,  but  the  return  code  is  "NOT  IN  USE"; 
GSAM  calls  MNIBA  via  R0UTX  to  establish  the  block,  then  MNIBD  to 
initialize  it  with  two  empty  text  entries.   The  text  entry  editor  in 
GUT1  is  now  called  with  an  XCTL  (return  data  is  first  placed  in  the 
level  3  return  of  the  console  vector)  and  with  parameters  indicating 
editing  of  entry  one,  block  6.   The  user  interacts  with  the  text  editor 
and  finally  returns  to  GSAM  where  the  console  vector  and  display  are 
reset  with  the  SPECFY  options  list.   RETURN  is  hit,  so  GSAM  returns  to 
its  main  three  option  mode;  RETURN  is  hit  again,  so  GSAM  returns  (exits) 
to  CALR. 

Functional  descriptions  of  CALR,  GNDR(GND1,GND2 ,GND3 ) ,  GUT1 
(the  text  entry  editor),  GUT3( REACT),  and  GSAM  are  presented  in  [7]. 
PSIR  appears  in  [6].   Detailed  information  concerning  these  segments' 
use  of  the  console  vector  work  area  and  the  PCB,  their  device  input 
procedures,  as  well  as  some  very  useful  subroutines  they  employ,  is  found 
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in  the  listings  (usually  the  first  few  pages  of  each).   Segments  of 
particular  interest  are  GND1  and  GUT3.  A  brief  resume  of  the  facilities 
provided  by  GUT2,  as  well  as  some  additional  information  on  GUT3, 
follows  below.   Detailed  procedures  for  calling  the  utilities  in  GUT2 
appear  in  the  listings;  LDNMBK  is  of  particular  interest  in  that  segment. 


REGEN 


This  routine  is  invoked  normally  ONLY  by  the  GREGEN  facility 
in  GLASP;  it  provides  a  means  for  regenerating  all  of  the  instance 
mnemonics  referenced  in  an  instance  block  (usually  block  2).  However, 
REGEN  can  be  called  by  segments  to  display  an  arbitrarily  located 
instance  block  (c.f.  REACT). 

During  automatic  redisplay  of  the  standard  visible  blocks 
(GREGEN),  the  existence  of  an  initialized  block  2  (instance  block) 
causes  GREGNE  to  XCTL  to  GUT2  at  entry  RGINST.   RGINST  assumes  that  the 
block  has  at  least  one  valid  instance  reference  (three  entries).   Each 
instance  reference  in  the  block  is  examined  sequentially;  the  instance 
name  and  Y,  X  position  are  extracted.   The  specified  mnemonic  instance 
block  is  loaded  from  IR  into  work  block  13n  by  an  internal  call  to 
LDNMBK  (see  below).   DPUM  is  then  used  to  create  the  appropriate  display 
files.   RGINST  eventually  returns  to  GREGNE,  using  console  vector 
locations  +51  to  reset  the  terminal's  current  program  ID.   The  terminal's 
return  address  was  stored  by  GREGEN  in  console  vector  location  +50. 

LDNMBK 

This  routine  loads  a  named  block  from  IR  into  the  specified 
block  of  the  current  picture  or  into  a  work  block;  the  listing  of  the 
routine  is  quite  descriptive  and  should  be  examined.   LDNMBK  can  be 
called  on  level  3  as  a  subroutine  by  any  segment;  it  is  also  called 
internally  by  RGINST  during  instance  block  display  (above)  or  by  LDNMHP 
(load  new  picture,  see  below). 
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SVNMBK 

This   routine   saves  the   specified  "block   (after  loading  it 
into  core  via  MNL0DR)   in  IR  with  the  indicated  name.      It  can  "be  called 
on  level  3  as  a  subroutine    (e.g.,   to  save  some  block  just   created)   or 
internally   (e.g.,  "by  SWMHP  for  each  block  in  the  current  picture). 
The  specified  block  is  unfixed  before  return. 

DUJMBK 

This  routine  deletes  the  indicated  named  block  from  IR.   It 
can  be  called  on  level  3  as  a  subroutine  or  internally  (e.g.  ,  by 
DLNMHP  for  each  block  in  the  specified  picture). 

SVNMHP 

This  routine,   called  on  level  3  only,    saves  the  FCB  and  all 
initialized  blocks   of  the   current  picture  in  IR  with  the  name   specified. 
Internal  calls  to   SWMBK  are  made   for  each  block  to  be   saved.      The 
specified  name   is   also   inserted  into  the  user's  menu  block   (see  below). 
Before  the   FCB  is   saved,   the   specified  name   is   inserted  at  its  beginning 
along  with  a  user  ID  of  0.      Hence,   IR  will  use  the   current  logged-on 
user's   ID  in  the  directory  entry  created. 

LDNMHP 

This  routine,  called  on  level  3  only,  loads  the  specified 
(named)  picture  from  IR  and  makes  it  the  current  picture.   First,  all 
blocks  of  the  old  current  picture  are  purged  from  core  with  MNDEB.   Then 
the  FCB  of  the  new  picture  is  loaded  from  IR.   Using  the  data  in  the  FCB, 
each  initialized  block  in  the  new  picture  is  loaded  with  an  internal  call 
to  LDNMBK.   After  being  loaded,  each  block  is  unfixed. 

DLNMHP 

This   routine,    called  on  level  3  only,   deletes  the  named  picture 
from  IR.      First,   the  FCB  is   deleted;   then  each  block  is   deleted  by  an 
internal  call  to  DLNMBK.      The  picture  name   is  also   deleted  from  the  user's 
menu  block   (see  below). 
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SVENMN 


This  routine,  called  on  level  3  only,  saves  the  current  contents 


of  block  12  _  with  the  specified  name — the  block  is.  assumed  to  be  a 
mnemonic  storage  block.  Before  calling  SVNMBK  internally  for  the  actual 
IR  save,  the  name  is  inserted  into  the  block,  along  with  a  user  ID  of  0 
(c.f.  SVNMHP).   The  name  is  also  inserted  into  the  user's  menu  block. 


DELNMN 


This  routine,   called  on  level  3  only,    deletes  the  named  mnemonic 
from  IR  and  the  mnemonic  name   from  the  user's  menu  block. 

(Note  that  a  routine  to  load  a  named  mnemonic  is  NOT  provided  since  this 
is   accomplished  merely  by   a  direct  call  to  LDNMBK) 

SNDHDR 

This   routine,   called  on  level  3  or  internally  by  SNDPC   (below) 
transmits   the   specified  block  over  the  2701  via  a  R0UTX  call  to   T027O1. 

SNDBLK 

This  routine,  called  on  level  3  or  internally  by  SNDPC  (below), 
transmits  the  specified  block  over  the  2701  via  a  R0UTX  call  to  T027O1. 
The  indicated  block  must  already  by  loaded. 

SNDPC 

This  routine,  called  on  level  3  only,  transmits  the  current 
picture  over  the  2701.   SNDHDR  is  first  called  internally  to  send  the 
FCB;  then,  after  appropriate  MNL0DR  calls,  SNDBLK  is  internally  called 
for  each  initialized  block. 

MEN  UP 

This   routine,    called  on  level   3   or  internally   (by  DLNMHP, 
DELNMN),    deletes  the   indicated  name   from  the  user's  menu  block.      The 
block  is    first   loaded  via  MNL0DR;   then  a  scan  routine   (MENUSW)    tries 
to  locate  the  name.      If  found,   the  name   is   removed  by  a  call  to  MNRPL 
which  compresses  the  block  at  that  point. 
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MENUA 

This  routine,   called  on  level  3  or  internally   ("by  SVNMHP, 
SVENMN) ,   adds  the  indicated  name  to  the  user's  menu  block.      The  block 
is   first   loaded;  then  MENUSW  tries  to  locate   the  name.      If  not   found, 
the  name  is   inserted  by  a  call  to  MNRPL  which  expands   the  block  at 
the  alphabetic  location  reached  by  MENUSW. 

MENUX 

This   routine,   called  on  level  3  or  internally,   extracts  the 
indicated  n-th  name   from  the  user's  menu  block.      For  example,  MENUX  is 
usually   called  after  a  menu  area  hit  in  GND1;   it  is   also  used  during 
CALR's  purgeout  processing. 


DIMEM 


This   routine,    called  on  level  3  or  internally,    displays  the 
first   32  names   in  the  user's  menu  block  in  the  menu  area.      After  loading 
the  menu  block,   DIMENN  enqueues  the  DPU  and  builds  the  display  file 
via  DPUE  calls.      The   file   is   sent  to  the  display;   DIMENN  unfixes   the 
block  and  returns. 

DIMNF1,    DIMNF2,    DIMNF3 

These   are   three   entry  points   in  DIMEM,    called  on  level  3, 
that   cause   display  of  the  second,   third,   and  fourth  32-name  groups, 
respectively,   in  the  user's  menu  block. 

REACT (GUT3) 

As  previously  discussed,   this  program  provides  generalized 
user-to-remote-program  communication  facilities.      Two   areas  bear  special 
mention;  the   first   involves   2701  record  handling. 

Unless   otherwise  altered  by  the  program  in  the   36Q    (see  below), 
user  keyboard  lines  and  joystick  hits   are  sent   directly  to  the  360.      Keyboard 
lines   are   sent  with  type=0 ,   joystick  hits  with  type=l.      The  format   is 
as   follows  : 
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Keyboard:   00N0  0000  OOnn  (packed  characters) 

+0   +1   +2   +3 .  . .  +nn+U 

+0  through  +2  are  the  usual  record  control  -words ,  as 
described  previously  (N  =  console  number,  0000  =  type, 
nn  =  length),  nn  is  ^_  k3n   since  the  maximum  character 
line  is  72 1Q  characters  (e.g.  T2/2  -  1  =  35  =  **3g) . 
This,  is  the  same  form  as  the  so-called 'Indicative  text  line 
messages"  sent  from  the  360  to  the  PDP-8. 

Joystick:   00N0  0001  0002  Y  X  n 
+0    +1    +2   +3  +k   +5 

+0  through  +2  as  above .   +3  and  +h   are  the  hit  coordinates , 
while  +5(n)  is  the  screen  segment  number  in  "which  the  hit 
occurred.  Note  that  REACT  has  a  special  test  to  use  any  hit 
in  the  system  message  area  (screen  segment  0)  as  an  EXIT 
REACT  request;  this  cannot  be  altered  by  the  360  program. 

In  addition,  as  described  in  [7],  REACT  can  transmit  pictures  and  mnemonics 
to  the  360.   The  record  types  for  these  blocks  are  identical  to  the 
convention  used  by  local  IR  as  presented  in  section  1.6  (IR) .   Moreover, 
LSD  uses  the  same  type-word  conventions  for  storing  picture  and  mnemonic 
blocks  in  the  360  remote  filing  system. 

Data  sent  to  REACT  from  the  360  looks  much  the  same.   Record 
type  =  0  is  an  indicative  text  message  line,  so  the  line  is  displayed 
on  the  terminal  in  the  next  available  location.   When  the  bottom  of  the 
draw  area  is  reached,  the  screen  is  erased,  the  frame  is  redrawn,  and 
the  "available  location"  pointer  (kept  in  +37  of  the  console  vector)  is 
reset  to  the  top  of  the  draw  area.   Records  with  the  high-order  bit  set 
on  (e.g.  i+xxx)  are  assumed  to  be  data  structure  blocks  composing  parts  of 
pictures  or  mnemonics.   All  other  records  (types  1-3777)  are  ignored 
(flushed).   For  data  structure  blocks,  type  bits  0077  specify  the  block, 
3600  specify  options,  4000  must  always  be  on,  and  0100  must  always  be  off 
(else  a  type  of  7770-7777  could  be  generated  which  would  be  confused  with 
a  monitor-monitor  internal  record).   The  options  are  listed  below;  bits 
are  numbered  high  order  (left)  to  low  order  (right),  0  to  11. 
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bit  0 :   1  ( always ) . 

"bit  1:  1  (replace  the  similarly  numbered  block  in  the  current 

picture  with  the  block  in  this  record) . 

0  (put  the  block  in  this  record  into  work  block  12n). 

bit  2:  1  (do  not  display  the  block  in  this  record). 

0  (display  the  block  in  this  record  immediately  on 

the  terminal). 

bit  3:  1  (before  displaying  block  (bit  2=0),  erase  screen 

and  set  available  location  pointer  to  draw  area  top). 

G  (do  not  erase  screen). 

bit  k:     1  (before  displaying  block  (bit2=0),  add  frame  to  the  screen) 

0  (do  not  add  frame). 

bit  5 :   0  ( always ) . 

bit  6- 

bit  11:   data  block  0  (FCB),  1  (line  block  0),  etc.,  or 

mnemonic  as  per  section  1.6  (IR). 

For  example,  type  =  U001  would  cause  the  block  in  the  record  to  be  treated 
as  a  line  block.   It  would  be  put  in  the  work  block  and  a  display  file 
would  be  created  from  it ;  this  file  would  be  sent  to  the  terminal 
immediately.  A  subsequent  type  U002  record  would  cause  a  text  block  to  be 
displayed  (the  old  contents  of  the  work  block  area  replaced  (lost)  by 
the  text  block).   In  both  cases,  the  current  picture  (FCB  plus  blocks 
0...11J  is  undisturbed.   A  type  700U  record  would  cause  the  current 
picture's  terminal  block  to  be  replaced  by  the  block  in  the  record;  no 
display  activity  occurs. 

Other  options  can  be  set  with  certain  words  in  the  FCB;  REACT 
currently  uses  only  the  first  six  words,  of  the  FCB.   The  first  four  words 
specify  a  picture  name  as  usual;  if  the  first  word  is  nonzero,  this  name 
is  put  into  the  current  picture  FCB.   The  fifth  word  specifies  the  "auto- 
save"  option: 

0  =  auto  save  off  (do  not  save  current  picture  in  IR) 

1  =  auto  save  on  (save  current  picture  in  IR) 

2  =  purge  (current  picture  is  purged  from  core) 


3^ 

The  sixth  word   (IMASK  in   CALLER/ COMMUNE )   sets  the  joystick  and  keyboard 
filter  of  the  console  vector;   this  word  is  always  saved  in  the  sixth 
word  of  the   current  picture  FCB,   except  when  auto-save  =  2   (see  below). 

hit   0:      echo   (0=display  keyboard  line  typed  by  the  user  on 
the  screen  at   the   available  location  after 
transmission  to  the  360 ;   l=no  display). 

bit  1- 

bit  9'      screen  areas  (l=accept  joystick  hit  in  corresponding 

screen  area  1-9;  0=do  not  accept), 
bit  10:  keyboard  (l=accept;  0=do  not  accept), 
bit  11 :  ( spare ) . 

A  typical  sequence  would  be:   l)  record  type  U000  (FCB)  with  fifth  word  =  2 
arrives;  the  current  picture  is  removed  (note  that  when  this  option  occurs, 
no  other  options  such  as  reset  name  or  alter  filter  are  executed);  2)  record 
types  7001,  7002,  7003,  7005,  and  7006  arrive  (in  any  order),  these  new  blocks 
(line,  text,  instance,  terminal,  and  first  nonstandard)  become  the 
respective  blocks  of  a  new  current  picture;  3)  another  record  type  U600 
arrives,  the  fifth  word  is  N0T=2  ,  so  other  options  are  examined.   The  first 
word  is  not  zero ,  so  a  new  name  is  put  in  the  current  FCB ;  the  sixth 
word  is  used  to  reset  the  console  vector  filter;  and  bits  0600  indicate 
the  screen  is  to  be  erased  and  the  frame  added.  However,  word  five  is 
examined  again  after  the  filter  is  reset  and  before  0600  is  tested.   The 
content  is  formed  to  be  1,  so  the  current  picture  (new  FCB  with  new  blocks) 
is  saved  in  IR;  0600  is  not  tested  in  this  case.  Note  that  700x,  460x,  and 
UoOx  records  can  arrive  at  any  time ;  hence ,  the  360  program  can  aribitrarily 
change  any  block  in  the  current  picture  (700x) .   Moreover,  the  current 
display  can  be  arbitrarily  changed  (U60x)  or  added  to  (^00x).   This  is  the 
essence  of  the  philosophy  behind  REACT. 

Mnemonics  can  also  be  saved  automatically  (but  not  displayed). 
Any  block  of  type  >U012  (e.g.  ^OUl)  is  considered  a  mnemonic;  these 
blocks  must  always  be  marked  for  "replace  in  work  block"  (type  bit  1=0). 
The  first  six  words  of  the  first  block  entry  are  examined;  if  word  five=l 
(as  with  an  FCB),  the  assumed  mnemonic  is  saved  in  IR  with  the  name 
supplied  by  the  first  four  words.   No  other  FCB  options  apply. 
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The  second  area  of  mention  is  a  short  note  involving  the 
display  of  an  instance  block  located  in  -work  block  12 „.   REACT  uses  a 
little  trick  to  call  GREGNE  to  accomplish  the  regeneration.   Consult 
the  listing  at  label  "C0MINS"  since  this  is  a  handy  procedure  to  know. 

REACT  has  many  interesting  sections  of  code  that  call  system 
functions  (e.g.,  send  picture,  send  block,  save  picture,  etc.).   One  of 
particular  interest  is  the  handling  of  input  data  structure  blocks  via 
MR2TB.   Consult  the  listing  at  label  "C0MMTB." 

Short,  annotated  flowcharts  giving  the  overall  flow  of  control  for 
currently  available  program  segments  are  found  in  Appendix  E. 


36 


REMOTE  SUBSYSTEMS 


As  is  shown  by  Figure  1,  three  subsystems  plus  "user  level 
programs"  (hereafter  termed  "programs")  comprise  the  remote  section 

of  GRASS. 

The  top  most  monitor  level  (G80PERAT)  is  responsible  for 
communicating  with  the  operator,  for  performing  the  actual  2701  I/O 
linking  the  remote  and  local  computers,  and  for  controlling  the  second 
level  of  the  monitor.   The  lower  level  (SPACT)  is  a  complete  multi- 
terminal  package,  capable  of  attaching  a  separate  task  (program)  to 
each  terminal.   Each  task  can  then  communicate  with  its  assigned  terminal 
and  with  the  filing  system  (XFILE) .   XFILE  provides  permanent  storage 
for  picture  and  other  data  generated  by  programs  or  transmitted  from  the 
satellite  PDP-8. 

Complete  descriptions  of  the  operation  of  the  2701  link,  XFILE, 
and  the  monitors,  from  the  viewpoint  of  the  terminal  user  and  his  programs 
are  provided  in  [8,  95  and  7l«   These  topics,  as  such,  will  not  be 
presented  here.   Information  for  generating  and  running  the  system  is 
found  in  Appendix  B,  Part  2. 

G80PERAT  is  considered  as  the  only  truly  permanent  (e.g. 
continuously  resident)  part  of  the  system.   Current  operator  commands 
include : 

S  name  parm  (start  second  level  module  called  "name"  and  pass 

it  "parm") 
ZAP         (unconditionally  stop  (e.g.  detach)  second  level) 
HALT        (request  second  level  to  stop) 

DUMP        (output  dumps  for  second  level  and  all  its  subtasks) 
NEVER       (execute  STAE  as  added  protection  against  bomb-out) 
UWEVER      (delete  STAE  condition) 
GRASS-0UT   (terminate  execution) 
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Whenever  the  second  level  is  NOT  attached,    any  input  records  from  the 
PDP-8  are   considered  to  be   operator  commands.      In  addition,   G80PERAT  can 
be  passed  a  command  as   a  parameter  when  it  first  begins  execution.      Some 
special  options  can  be  specified  in  this  last  case:      use   of  the  WT0R's 
for  communicating  with  the  360  machine  operator,   as  well  as  use  of  the 
system  timer,   can  be  suspended. 

G80PERAT  uses  the   "P8"  type  macros   (see  below)    for  direct 
communication  with  the  2701.      All  hardware  error  diagnostics  and  retries 
are  performed  on  a  given  read  or  write   operation  by  G80PERAT.      No 
assumptions   are  made  about  the  data  nor  is  the  data  transformed  in  any 
way   (except,   of  course,   in  the  case  of  command  records).      Records  are 
read  or  written  only  as   requested  by  the  second  level  of  the  monitor. 

The  system's   second  level  can  by  any  program,   and  more 
specifically,  might  be  any  program  using  the   "G8"  type  macros    (see 
below)   to  request  G80PERAT  to  read  or  write  over  the  2701.      In  particular, 
the  second  level  currently  used  is  the  multi-terminal  package,   SPACT. 
SPACT  has   several  functions,   the  primary  being  the   attaching  or  detaching 
of  any  program  module  associated  with  any  given  user  terminal  in  the  system. 
SPACT  also  maintains   an  input/output   record  queuing  system  to   allow  each 
program  in  the  360  to  communicate  with  the  terminal  to  which  it  is  attached, 
Any  2701  input  record  of  type=0    (c.f.    G8-macro  descriptions)  with  first 
character  of  "!"   is  assumed  to  be   a  SPACT  command.      All  other  2701  input 
is   assumed  to  be  data  for  the  attached  user  programs.      SPACT   only 
examines  the  data  portion  of  command  records .      The  data  of  all  other 
records  is   solely  the  responsibility  of  the  issuing   or  receiving  program 
module.      The   format  of  2701  records   is   adequately  described  in    [9];   long 
data  records   are  handled  with   a  two-part  transfer  as   discussed   in  F027O1 
(section  1.6) . 

Any  user  program  can  run  under  SPACT,  but   again,   those  of 
particular  interest  are  the  ones  that  communicate  with  the  terminals  via 
the  2701.     Examples   are   LSD  and  the  various  modules  of  the  Simulation  and 
Modeling  System   [5,   8].      These  modules  utilize  the  S8-macros    [9]   to   fetch 
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records  out  of  SPACT's   input  queue  or  place  records   into  its  output 
queue.      Since  the  relationship  of  program-to-terminal  is  maintained  by 
SPACT,   any  program  can  be  attached  to  any  terminal.      Furthermore,   the 
S8-macros  can  be  used  in  re-entrant  programs,   so  if  more  than  one  terminal 
wants  the  same  program  simultaneously,  only  one  copy  of  the  program  need 
be  in  core.      For  similar  reasons,   re-entrant  user  program  linkage  to 
XFILE  is   also  possible    [9]. 

In  the  following  discussions,   some  knowledge  of  0S/36O 
programming  has  been  assumed.      Note  that  the  entire  monitor  and  XFILE 
complex  runs  exclusively  in  bulk  core;  appropriate  use  of  HIARCHY=1  has 
been  made  throughout    (GETMAIN,  ATTACH,   LINK,   L0AD,   XCTL,   etc.).      The 
monitors   and  XFILE  require   approximately  18-20K  bytes  of  memory;  the 
number  and  size  of  user  programs   to  be   run  concurrently  under  SPACT 
dictates  the  total  memory   space    (REGI0N)   that  must  be   assigned  to  the  job. 

2.1     G80PEPAT 

The  overall  flow  of  control  for  this  module   is   shown  in 
Figure  15.      Salient   features   include:      (numbers   refer  to  indicated 
flowchart  boxes) 

1.      All  G80PERAT  flags   are  set  to  0    (off).      The  PARM  field 
from  the  0S  EXEC  statement   is   examined  for  initial  parameters.      The  2701 
link  is  made  available  via  0PEN  and  ENBATN   (enable  attention)  macro  calls. 

Note  that  ENBATN  is   a  simple   installation  0S  modification  that 
allows   a  program  to  realize  that  a  device   desires   service .     Such  a 
facility  is  not  normally  available  in  0S  360  but  is  usually  added  at 
installations  where   timesharing  systems   are  hung  on  360  machines. 

The  parameter  string  format   for  the  PARM  field  is: 

[ [option] [command] ] 

Valid  "options"   are  NM,  MS,   NT,   TM,   and  {NM,MS}{NT,TM} ;   an  example  of  the 
last  is  MSNT.      Unless  overridden,  MS  and  TM  are   assumed  by  G80PERAT.      The 
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"command"  is  always  passed  to  the  operator  command  analyzer  as  if  it  had 
been  received  from  the  3^0  operator.  This  is  a  handy  debugging  aid  and 
is  also  convenient  for  starting  SPACT  (e.g.,  command  =  S  SPACT)  automatically, 
Any  G80PERAT  command  can  appear  in  "command." 


MS 
NT 
TM 


do  not  issue  WT0R's  to  operator 
issue  WT0R's,  as  normal 
do  not  use  system  timer 
use  system  timer,  as  normal 


2.  Await  an  event  or  system  timer.  An  0$  (and  HASP)  feature 
exists  that  causes  termination  of  a  job  if  that  job  remains  in  the  wait 
state  (inactive)  for  more  than  a  certain  number  of  minutes.   Since  this 
is  an  interactive  monitor,  the  possibility  of  a  long  wait  between  events 
exists.  Hence,  the  system  timer  is  used  to  interrupt  G80PERAT  (make  it 
active)  periodically  to  avoid  cancellation.   During  debugging,  use  of 
the  timer  in  this  manner  is  often  not  desired,  hence  the  NT  option. 

3.  Execute  the  indicated  command.  All  commands  have  the  form 
Verb [Object] [parameters]  where  Verb  is  the  field  tested  by  the  command 
analyzer.   It  is  the  responsibility  of  the  routine  that  executes  the  Verb 
to  test  and  use  the  remaining  fields  as  needed.   ZAP,  HALT,  DUMP,  NEVER, 
UNEVER,  and  GRASS-0UT  as  listed  previously  are  straightforward  and  self- 
explanatory.   Only  "S  name  parm"  (start  second  level)  need  be  discussed  here 

G80PERAT  uses  an  ATTACH  macro  to  begin  execution  of  module 
"name"  as  a  subtask.  This  subtask  is  passed  a  parameter  list  address  in 
register  1;  the  list  format  is: 

+0  0 

+k     A( request  ECB's) 

+8  A(parm  string) 

The  subtask  must  P0ST  the  first  location  in  the  list  when  it  begins 
executing  (c.f.  G8ENTRY  macro  description).   This  notifies  G80PERAT  that 


ko 


the  subtask  has  indeed  begun  executing;  G80PERAT  will  then   continue 
normal  processing.      If  0S  360  P0ST's  the  task-termination  ECB  specified 
in  the  ATTACH  macro  before  the  subtask  Pj&ST's   its  location,   G80PERAT 
assumes  execution  of  the  subtask  never  started   (module  not  found, 
insufficient  core,   etc.). 

When  G8ENTRY,   in  the  subtask,   P0ST's  list   location  +0, 
it   also  inserts  the  address  of  a  subtask  ECB  into  the  location.      If 
G80PERAT  P0ST's  this  ECB,   the  subtask  must  terminate  processing;   this 
ECB  is   tested  whenever  the  subtask  issues  a  G8WAIT  macro.      A  HALT 
command,   or  a  GRASS-0UT  command  while  a  subtask  is  executing,  will  cause 
G80PERAT  to  P0ST  this   subtask  ECB. 

The  subtask  G8EHTRY  macro  also  extracts  the  information   at 
+k  and  +8  in  the  list.     Whenever  the  subtask  desires  2701  input  or  output, 
the  appropriate  ECB  in  the  pair  pointed  to  by  the  address   at  +k  must  be 
P0STed.      The   subtask  inserts  the  address  of  a  record  request  block  into 
the  P0STed  ECB    (c.f.   G8-macro   descriptions).      The    "parm"   field  in  the 
start   command  is   copied  into   a  3^  byte   area  before  the  ATTACH  is   issued; 
the  address  of  this   area  is  placed  in  +8  of  the  list.      Access   to  the 
parameter  is  thus  provided;   if  no  parameter  was   specified,    "$N"   is  placed 
in  the  area. 

Figure  l6   summarizes  these  linkages  between  G80PERAT  and 
its   subtask. 

k.      Indicate  2701   operation   complete.      G80PERAT  uses   the  subtask 
record  request  block  address   found  in  the  appropriate   read  or  write 
request  ECB.      The   first  word  at  this   address   is   P0STed  by  G80PERAT  with  a 
completion  code.      Consult   Figure  l6. 

5.      Execute   2701  operation.      The  P8-macros,    described  below,   are 
used  to  transmit   data  to  the  PDP-8.      The  G8-macros   used  by  subtasks   are   also 
described  here  to  increase  understanding  of  their  interaction  with  G80PERAT. 
Consult  Figure  l6. 
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Necessary  information  is  extracted  by  G80PERAT  from  the 
indicated  record  request  block;  P8EETRY  is  used  to  perform  the  desired  read 
or  write  operation.      The  actual  transmission  routines   are  generated  by 
P80PRS  and  P80PRSX.      Lower  level  P8-macros    (P8RCCW,   P8WCCW,   and  P8WAIT) 
are   available  for  more   flexible  use  of  P80PRS  facilities. 

label  P8RETRY0P,   data  addr,   len,   retry  count    [,ECBLST=,  0THER=] 

Generates : 

BAL  1,   *+20 

DC  A (data  addr) 

DC  ALl( retry  count) 

DC  AL2(0P) 

DC  AL2(len) 

DC  A(ecb  list) 

DC  A(other  evert  routine ) 

BAL  Ik,   PDP8RTRY 

(Rl  points  to  params ,   RlU  is  the   return   register) 

0P  is  X'll1    (WRITE),   X'121    (READ),   or   (R)    (X'll'    or  Xf12'    is  in 
register  R) .      Retry  count   should  be  less  than  20. 

ECBLST  and  0THER  are  optional: 

ECBLST  is  the  address   of  a  list  of  ecb   addresses   containing 

at  least    'PDP8ECB'    BUT  NOT    'PDP8ATTN'. 

If  omitted,    a  list   containing  only    'PDP8ECB'    is  used. 

0THER  is  the  address   of  a  routine  to  be  entered  if  an  ecb 
is  posted  besides    'PDP8ECB'    (i.e.   ECBLST=lab  was   coded). 

Rl     =  A( ecb list) 
RlU  =   return   address 
R15  =  routine  address 

The   routine  must   "take  note,"   clear  the   appropriate  ecb,   and 
return  via  KLk  to  await   I/O  quiescence.      The  routine  must  save 
registers   0,  1,   13,   lh,  15- 

On  return   from  P8RETRY,  the  operation    (including  any  needed  retries)   is 
complete   and  R15=0K(O),  ERR(*0  ,   T0(8),   or  ATTN( write   only)    (12). 
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Note  that  on  initial  entry  to  PDP8RTRY  for  READ,  the  system  assumes 
'PDP8ATTN'  has  already  been  posted  and  then  cleared  by  caller.   If 
retries  are  needed,  the  system  waits  for  a  new  posting  of  'PDP8ATTNf 
before  each  retry.   If  such  a  post  does  NOT  occur  within  10  seconds, 
retry  processing  is  terminated  and  R15=8(T0)  is  returned  to  the 
calling  program. 


P80PRSX 

(contains  the  actual  retry  routines   and  linkages  to  P80PRS) 

P80PRS 

(contains  the  actual  2701  I/O  routines,  DCB,  I0B,  ECB's,  etc.) 

Generates : 

PDP8READ  (start   read  operation) 

PDP8RITE  (start  write  operation) 

PDP8EXCP  (start  EXCP  I/O  as   indicated  by  PDP8READ  or  PDP8RITE) 

PDP8WAIT  (await  EXCP  completion) 

PDP8DCB  (link  to  2701) 

PDP8ELST  (default  ECB  list   for  PDP8WAIT) 

PDP8ECB  (EXCP   completion  ECB) 

PDP8ATTN  (2701  attention  ECB  posted  by  0S) 

Ihe  user   (e.g.,   G80PERAT)   must  issue 

0PM      ( PDP8  DCB ,  ( INPUT )  ) 

ENBATN   DCB=PDP8DCB,ECB=PDP8ATTN 

oefore  using  the  2701  facilities  and  must  issue 

ENBATN   DCB=PDP8DCB 
CL0SE      (PDP8DCB) 

oefore  exiting  to  0S  when  the   job   terminates.      Also,   a  DD  card  named 
'PDP8DD'   must  be   included  in  the  job's   JCL  to   define   the  2701: 

//PDP8DD     DD     UNIT=021 

Note  that   if  a  delay  in  dispatching  the  task   occurs,   it   is  possible  that 
"PDP8ATTN1    or  some  other  ecb  may  have  been  posted  between  the  time 
'PDP8ECB'   was  posted   (Operation  complete)    and  the  time   control   is   returned 
to  the   calling  program.     Hence,    care  should  be  exercised  in  the  use  of 
any  "safety"   clears   of  ecb's. 
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label  {p8WCCW*   data  addr>    len 


Generates : 


BAL     ik,   PDP8READ 
BAL     Ik,   or  PDP8RITE 

RO  contains  the  byte  len:      if  >i+095,  this  must  be  specified  as   in  a 
register,   i.e.,    'data  addr,(R)'. 
Rl  contains  the  data  addr. 

The  above   call  results  in  the  generation  of  a  simple   COW;  this 
CCW  is  then  passed  to  PDP8EXCP  to  perform  the  actual  operation.      P8RCCW 
and  P8WCCW  are  used  in  conjunction  with  P8WAIT  to  give  the  program  complete 
control  over  the  I/O  operation.      P80PRSX  actually  uses  P8RCCW,   P8WCCW, 
and  P8WAIT.      Note  that  performing  complex  I/O  functions   is  possible. 
Instead  of  using  P8RCCW  or  P8WCCW,   the  program  can  build  its  own  chain 
of  CCWS.      Then  the  program  executes  BAL  1U,PDP8EXCP  with  the  address  of 
the  CC¥  chain  in  register  1. 

label  P8WAIT  ecbaddrlist ,0Kaddr,ERRaddr,T0addr[ ,N0T27Olecbaddr] 

Generates : 

BAL  Ik  ,PDP8WAIT 

B  0Kaddr  successful  completion  return 

B  ERRaddr  hardware  error  return 

B  T0addr  timeout   return 

[B  N0T2TOlecbaddr  return  if  event  other  than  2701   occurs] 

Rl  contains  the  address  of  the  ecb-address  list :      this   list  must   contain 
at  least  PDP8ECB .      If  only  PDP8ECB  is   included,    'N0T27Olecbaddr'    should 
be  omitted.     PDP8ELST  may  be  used  for   'ecbaddrlist '    in  which  case   only 
PDP8ECB   in  a  standard  list  will  be  used.      In  the  event   of  a    ,N0T27Olecbaddr' 
return,  the  program  must   "take  note,"   clear  the  appropriate  ecb,    and  issue 
a  new  PoVAIT . 


G8ENTRY  termecb 

Generates : 

G8RWC0M  (request  read  or  write  from  G80PERAT) 

G8WTC0M  (await  operation  completion) 

G8RDECB  (record  request  block  1  (READ)) 

G8RTECB  (record  request  block  2  (WRITE)) 
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This  macro  must  be  issued  by  the  subtask  of  G80PERAT  after  addressing  is 
established  but  before  register  1  is  destroyed.  Besides  linking  the 
subtask  to  G80PERAT,  G8ENTRY  contains  the  routines  used  by  G8READ,  G8WRITE 
and  G8WAIT  for  communicating  2701  records  via  G80PERAT.   The  subtask  must 
provide  a  vord  to  be  used  as  the  HALT  request  ecb  at  'termecb'. 

,   ,     .,  rG8READ    i    a    , 

label  GflWRTTF     ^a^a  addr,   len 

Generates : 


BAL  1,   *+12 

DC  A(data  addr) 

DC  X'00',   ALl(0P),  AL2   (len) 

BAL  iU,G8RWC0M 


label  G8WAIT  ecb   list   addr   [ ,0THER=routine   addr] 

Generates : 

BAL     lU ,G8WTC0M 

R0  contains   0  or  the   routine  address  of  an   'other-event'    routine,   Rl 
contains   addr  of  ecb   addr  list    (minimally:     G8RDECB  and  G8RTECB;   usually 
plus   terminal,   etc.)    Blk  is   return   register. 

On  return,  R15=0K(O),  ERR(U),  T0(8),  or  ATTN(write  only)  (12).  On  'other- 
event'  routine  entry,  the  program  must  take  note,  clear  the  ecb,  and  issue 
a  new  wait  as   in  P8WAIT . 

2.2     SPACT 

The  overall  flow  of  control  for  this  module  is   shown  in 
Figure  17.      Salient  features   include:      (numbers   refer  to  indicated 
flowchart  boxes ) 

1.      Set-up  to  begin.      G8ENTRY   is   called  to   link  SPACT  to 
G80PERAT;   XFILE  is   L0ADed  and  its   entry  address   saved.      SPACT  then  sends 
a  monitor-monitor  record  to  the  PDP-8 ;   this   record   (type=7770)    indicates 
to  the  PDP-8  that  the  360  is   available. 
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2.  P0ST  G80PERAT  with  read  request.   Since  a  P0ST  is  used, 
care  must  be  taken  that  a  second  P0ST  does  not  occur  before  G80PERAT 
clears  the  first.   Three  special  tests  are  thus  performed  before  SPACT 
issues  its  outstanding  G8READ  request. 

3.  Await  event  including  2701  Eead/Write.   The  test  for  part  1 
or  part  2  of  the  record  that  appears  in  the  flowcharts  at  B  and  C  is 
really  taken  care  of  by  the  code  after  the  G8WAIT.  Whenever  a  read  or 
write  is  started,  the  initializing  routine  sets  the  appropriate  return 
address  into  WTRET  or  RDRET. 

k.      Execute  the  indicated  command.   After  removing  the  leading 
"!,"  SPACT  commands  are  identical  in  format  to  G80PERAT  commands.   All 
are  self-explanatory  except  for  Start,  which  will  be  discussed  briefly 
here.   Start  works  exactly  the  same  in  SPACT  as  it  does  in  G80PEFAT, 
except  that  the  parameter  list  is  different  and  S8ENTRY  performs  the 
linkage  from  user  programs  to  SPACT.  Consult  [9].   The  linkage  performed 
by  S8EWTRY  is  shown  in  Figure  18 ;  the  terminal  control  area  for  each 
terminal  is  shown  in  Figure  19. 

As  general  information,  note  that  the  S8-macros  interact  with 
SPACT  in  a  manner  directly  analogous  to  the  interaction  of  the  G8-macros 
with  G80PERAT.   Furthermore,  as  is  obvious  from  Figure  IT,  SPACT  transmits 
long  records  in  two  parts  in  a  manner  directly  analogous  to  the  operation 
of  T027O1  (section  1.6). 
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addr 

+0 
+1 
+2 

+3 


+k 
+5 

+12 
+13 


contents  • 


function 


+50 


+77 


\  service  request  return  data 


CIF  CDF 

ADDR  0 

Request  No.  (0=free(No  Request),  >0=Service  Requested 

-l=Service  Being  Processed)  0 

Cons ole  Status  ( 0=inactive ,  4000=of f line , 2000=active , 

>2000=console  input  pending)  0 

Input  flags:  010  000  00A  BCD  (A-D=timer,  DPU,  operator, 

2701,  respectively) 

Prog  ID  (0-31)  0 


initially 


0 


'PSN0NAMEABCD' 
USER  ID 


(8  bits-Acct  No, 4  bits- 
User  No. ) 


+14 

Interval  Durati 

on 

^ 

_ 

+15 
+16 

Zero  or  nonzero 
Interval  Count 

/   Timer  Queue  Element 

0 

+17 

Interval  Duration 

Reset 

J 

- 

+20 

2701 

^ 

— 

+21 

Operator 

V  Console  Input  Prog  Entry 

- 

+22 

DPU 

[Addresses  (zero  on  entry 

- 

+23 

Timer 

)    from  caller) 

- 

+24 

Screen  Seg  #0 

> 

- 

. 

\  Joystick  Input  Filering 
J  Control 

+35 

Screen  Seg  #9 

_ 

+36 

Keyboard  input 

control  ( 

routine  address  or  0) 

- 

+37 

2701  Indicative 

message 

control  (next  screen  Y) 

- 

+1+0 

SVPRM1 

1 

- 

; 

/Service  Parameter  Save 

• 

+47 

SVPRM8 

J  Area  During  GUTS  Call 

- 

/Workspace  Save  Area 


Figure  3 .   Console  Vector  Detail 
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addr 
+0 

+57 


contents 


function 


Current  file  Data  block  allocation 

Control  block   (FCB) 


+60(10) 
+6i(ll) 

+70(12) 
+7M13) 


Work  blk 
Re  gen  blk 

Spare 

Menu  blk 


Mnemonic   construction,   commune 

temporary,   etc. 

Work  area  for  instance   regeneration 


Local  file  names   control 


+100 

BLKNUM 

+101 

(lockout) 

+102 

Spare 

+103 

Spare 

+10  k 

SHDPERG 

+105 

SHDPTR 

+106 

SHDRGN 

+107 


Address  of  last  blk  investigated 
Special  lockout  flag  (-1) 


ENT0RG  before  last  reset 
P0INTR  before  last  reset 
Blk  no  of  instance  block 
during  regen 


Spare 


+110 

MNM0D(O) 

+111 

Spare 

+112 

YH 

+113 

XH 

+111+ 

Y  scan  (1000) 

+115 

X  scan  (1000) 

+116 

Spare 

+117 

Spare 

P0INTR  displacement  (idle  value  =  0) 

Y  position  on  J.S.  bit 
X  position  on  J.S.  hit 
Draw  area 
reference  center 


+120 


+177 


PCW0RK 


Program  segment  scratch  area 
(kO   words  =  80  characters 
8  words  =  control) 


Figure  k.      Picture  Control  Block  (PCB) 
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addr  contents 


+0 

+k 

+5 

+6 

+7 

+10(0) 

+14(1) 

+20(2) 

+24(3) 

+30(4) 

+34(5) 

+5^(9)  User   5 

+5T-End 


Six  character  name  plus   two  spare   characters 

Spare    (0) 

Spare    (0) 

Protection 

User  ID 

Local  lines  -v 

Comment  text  l  System  standard  data 

Subpicture  instances  /  "block  control  entries 

(Reserved)  J 

Terminal  Types,  Connections,  and  Terminals 

User  1 

User  defined  data 
block  control  entries 


} 


Figure   5a.      File   Control  Block 


Word  1 


CIO  000  0NN  NNN  C=0(incore)    or  l(not) 

I=0( initialized)    or  l(not) 


NNNlJN=number  blocks   allocated  or  0 


Word  2 


FUA  AAA  A00  000  F=0(not  fixed)  or  l(fixed) 

U=( reserved) 
AAAAA=block  addr  in  DSBANK 

Words  3 

ENT0RG   last  used  for  this  block;   saved  here   on   return   from  any  DSMN  routine. 

Word  k 

P0INTR  last  used  for  this  block;   saved  here   on  return  from  any  DSMN  routine, 

Figure   5b.      Data  Block   Control  Entry  Detail 
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PCB  supplied  control  itemt : 

BLKNUM=j  (block  under  consideration) 

BLKORG=A  (starting  addr) 

ENTORG=;B  Gentry  in  block  under  consideration) 

-.POINTH»C.  (data  in  entry  under  consideration) 

block  j   control  entry: 

allocated  blocks    (NNNNN)=LL 

Core  addr    (AAAAA)=A 

control 


DS  BANK  data  block: 


data 


B+e 


A+L 


—  disp  to  end=L* 
pdisp  to  next** 

i-disp  to  next=e 


•{  data ) 


,disp  to  next 


■END 


A+LL- 


-(allocated) 


Disp-to-end  ALWAYS  <   20U8   (i.e.,   positive);   hence,  maximum  len  of 
data  in  a  block  <   20^7. 

**     Disp -to-next -entry  ALWAYS  <   20>+7   (i.e.,    <  L)  ;  hence,  maximum  len  of 
data  in  an  entry  <  20k6. 


Figure  6.      PCB   Control   and  Data  Structure   Relationships 


Lk 
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-Disp  to  End 

-Disp  to  next  entry  -  entry  1  (PT-PT  lines) 

Displacement  applied  to  all 
points  in  entry.   12 -bit  signed 
numbers.  Ususally  =  (0,0) 

Four  word  line  or  symbol  group. 
Y  ,  X  is  starting  point. 

If  S=0,  IX     is  ending  point 

If  S=l,  Y  X     is   a  reference 

to   a  closed  vector-generated 
symbol  centered  on  IX.      The 

symbol  is  inserted  into   display 
file   during  display  operation. 

Y,  X  are  absolute  points  w.r.t.    (0,0) 


dY 

dX 

0 

Yl 

0 

Xl 

s 

Y2 

X2 

END 


Figure  7«   Line  Block  (No.  0) 


— Disp  to  End 

r~Disp  to  next  entry  -  entry  1  (standard  text  entry) 

Absolute  point  w.r.t.  (0,0)  which  gives 
the  upper  left  coordinates  for  the 
top  line  in  a  contiguous  line  group. 


Yl 

xl 

len 

\ 

text 

Ai 

len 

Bi 

text 

Bi 

'Disp  to  next 

Y2 

\ 

len 

A2 

text 

A2 

len 

B2 

text 

B2 

len  =  number  of  words 
of  text 

entry  2      text  =  string  of  trimmed 

ASCii  characters, 
two  per  word 


entry  i 

'END 

Figure  8.   Text  Block  (No.  l) 
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i~ Disp  to  End 

rDisp  to  next  entry- 
Name  1,2 
Name  3  ,** 
Name  5  >6 
Name  Option 
0  Y 
0  X 
00   (INST  SEQ  NO) 

USER  ID 
J*Disp  to  next  entry 
Y 
X 

Li 

Text  1 

L2 

Text  2 

HDisp  to  next  entry 
13UU 
0 

Li 

Text  1 

L2 
Text  2 


entry  1  (control  for  first  instance) 
six  character  name  of  mnemonic 


two  character  option  (koko-kok'j) 

position  of  instance  center 

w.r.t.  (0,0) 

identification  number  assigned  to 

this  instance 

( creators ) 

entry  2  (Parameter  Assignment) 

standard  text  entry 
(c.f.  block  1) 

(but  Y,  X  relocated  w.r.t.  entry  1  Y,  X) 
parameter  values  assigned  to 
this  instance 


-  entry  3  (type  name  list) 

standard  text  entry 
(c.f.  block  1) 


type  names  referenced  by 
terminals  of  this  instance 


'Disp  to  next  entry  -  entry  k   (control  for  second  instance) 


every  three  entries  specify 
a  mnemonic  instance 


END 


Figure  9-   Instance  Block  (No.  2) 
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Disp 

to  End 

Disp 

to  next  entry 
Y  =  13UH 

X  =  0 

Li 

TXT 

L2 

TXT 

-  entry  1  (type  name  list   for  local  terminals) 


standard  text  entry 


*Disp  to  next  entry     -  entry  2   (terminal  connection  list) 
VO(FROM  TRM  SEQ  WO) 
00(T0  TRM  SEQ  NO)        V=l,  visible   connection;  =0,  invisible 

FROM  (TRM  SEQ  N0)!s   are   10  bits  each 

TO 


^Disp  to  next  entry 
0D(INST  SEQ  NO) 


V0  (TRM  SEQ  NO) 


A0  (TYPE  NAME  NO) 


00    (Y) 
00    (X) 
T)isp  to  next  entry 


L 

■*"END 


-  entry  3   (first  terminal) 

0=1,  local  terminal;  =0,  terminal 
belongs  to  a  subpicture  instance 

D=l,  external  (0  must  =  l) , 
=0,  internal 

(INST  SEQ  NO)  is  10  bits  specifying 
subpicture  instance  to  which 
terminal  belongs  (e.g.  if  0  =  0) 

V=l,  blank  numeric  data  during  display; 
=0,  normal  terminal  display 

(TRM  SEQ  NO)  is  10  bits  specifying 
identification  assigned  to  this  terminal 

A=l,  type  not  assigned;  =0,  type  assigned 

(TYPE  NAME  NO)  is  10  bits  indicating 
type  name.   If  terminal  is  local  (0=1) 
reference  is  to  entry  1  of  this  block; 
if  an  instance  terminal  (0=0), 
reference  is  to  type  name  list  in 
instance  entry  specified  by  (INST  SEQ  NO). 

Center  of  terminal  symbol 

-  entry  k   (second  terminal) 


Typical  instance/internal  terminal  appears  as   .      where  'b3T'  is 
generated  from  (TRM  SEQ  NO)  and  'b'  is  generated  from  0D 

Figure  10.   Terminal  Block  (No.  k) 
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Disp  to  End 

f-Disp  to  next  entry- 
Name  1,2 
Name  39h 
Name  5  ,6 
Name  option 
Spare  1=0 
Spare  2=0 
00  protection 
User's  ID 
"Disp  to  next  entry 
Y 
X 

h 

Text 

V 

Text,. 


Disp  to  next  entry 
Y  =  13UU 
X  =  0 

Li 

Text 

L2 

Text„ 


^)isp  to  next  entry 
A0  (TYPE  NAME  NO) 

Yi 
xi 

AO  (TYPE  NAME  NO) 


Disp 

to  next 
dY 
dX 
PT  Y 

PT  X 

PT2Y 

PT2X 

entry 

entry  1  (control) 
six  character  name 


2  character  option  (UoUO-h-OUT) 


(c.f.   block  2) 

creator's  ID,  not   current  user 

entry  2   (parameter  model  list) 


standard  text  entry 
(c.f.   block  1) 


-  entry  3    (type  name  list) 

standard  text  entry 
(c.f.  block  1) 


entry  k   (terminal  list) 

A=l,   type  not   assigned;  =0,   assigned. 

(TYPE  NAME  NO)   is   index  into  entry  3 
of  this  block 

List   corresponds   in  order  to  external 
terminals   in  structure   definition 


-  entry  5    (lines) 


standard  line  entry 


(c.f.   block  0) 
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~Disp  to  next  entry       -  entry  6  (comment  text) 
"  .    Y 
X 
L  standard  text  entries 

Text  (c.f.  "block  l) 

L2 

Text„  none,  one  or  several  of 

these  entries  may  be 
'.  present 

-  entry:   (comment  text) 


I 


END 


Figure  11.   Mnemonic  Storage  Block  (M.S.B.) 


■Disp  to  End 

■Disp  to  next  entry       -  entry  1  (only  entry) 

Name  0  each  'name'  is  four  words  lon| 

6  characters  plus  type  word 

Name  127 

'END 

Figure  12.  Menu  Block 
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lUUo. 


Xklk 

1370 


170 

Ikk 

120 

Ik 

50 

2k 


a  SYSL   ? 

2tLINES 

0  USEL   V 


3  TIME 


-•.(1023,800) 


11 


1  MENU 


32 -LINES 


< 10 7-: 

characters 


2  ANSWER 
3 -LINES 


4- 


3  YES/NO 
2 -LINES 


k   DRAW  AREA 


-136U 


MC 


DC 


75 

characters 


5  PROMPTS 


■<*l6k 


6   LIGHT  BUTTONS 


9   PANIC 
KLO -CHARACTERS- 


KEYBOARD  INPUT   LINE 


-irr- 
i 

170 
l6h 


-<=-70 


n — 

160k 
1600 


1777 


DC  (Draw  Area  Center)  =  (107^,  71*0 

MC  (Mnemonic  Center)  =  (1000,  1000 ) 

Draw  Area  =  6U0  by  90U  points  (U.5"  by  7-5") 

Characters  =  8  by  12  points  set  in  the  lower  left 

corner  of  12  by  20  point  areas 
The  number  to  the  left  of  each  area  name  designates  that  area 
(e.g.,  the  Draw  Area  is  screen  segment  k) 

Figure  13.   Display  Screen  Composition  Detail 
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number 

0 
1 
2 

3 
h 
5 
6 

7 
10 

11 

12 
13 
11+ 

15 
16 

IT 
20 
21 
22 
23 
2h 


25 
26 
27 


30 
31 
32 
33 
3k 
35 
36 
37 


name 

CALR 
GSAM 
LLSD 
ARCH 
TEXT 
(etc. ) 


GND1 
GND2 
GND3 


function 

Logon /program  menu  (SYSTEM) 
Simulation  and  Modeling 
Library  Manipulation 
Architectural  Design  Aid 
Document  Preparation 


)  (APPLICATIONS) 


generalized  drawing 
package 


>) 


GUT1  (mini  text  editor) 

GUT2  (regen,  file,  send,  menu) }  Utility  Functions 

GUT3  (REACT) 

DEX1        S 

DEX2        1      Logon  directory  extensions      (SYSTEM) 

DEX3        J 

SPIR  (Spare) 

PSIR  IR  initializer/blk  sorter 


Figure  ik.      Program  Segment  Allocation 


START 


1 

INITIALIZE 
FLAGS,    OPEN 
PDP-8   LINK. 
INDICATE  EXEC 


■0 


6o 


MSG 


SEND 

MESSAGE  TO 
360 
OPEFATOR 


M 


SET  SYSTEM 
TIMER, 
AWAIT  AN 
EVENT 


(Event  Occurred) 


Jwo 

(ABEND  since 
invalid  event) 


Figure   15.      G80PERAT  Flow  of  Control    (Part   1  of  2 ) 


RETURN 
INVALID 
COMMAND 
MESSAGE 


PERFORM 
COMMAND.  RETUBI 
APPROPRIATE 
MESSAGE 


-Wmsg\ 
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CLEAN  UP 
TCB 


MSG 


YES 


CLOSE  PDP-8 
LINK,  IN  DIC  ATE 
FINISHED 


Exit  to   0S/36O 


YES 


CONVERT  TO 
EBCDIC 


MARK  INPUT 
PENDING 


PERFORM  READ 
WITH  TIMEOUT 
AND  SAFETY 
TIMER 


INDICATE 
RESULT  TO 
SECOND  LEVEL 


MARK  SECOND 
LEVEL 
REQUESTED 
READ 


YES 


PERFORM  WRITE 

WITH 

TIMEOUT 


INDICATE 
OUTPUT  BROKEN 
TO  SECOND 
LEVEL 


INDICATE 
RESULT  TO 
SECOND 
LEVEL 


<D 


<D 


Figure  15-      (Part  2   of  2) 
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After  G80PERAT  ATTACH  of  subtask,  "but  before  G8ENTRY  call: 

Parmlist  for  subtask  Subtask 

+0  0  ( Unknown ) 

+k     A( RDRQECB) 
+8  A( STRING) 

G80PERAT 

RDRQECB  =  0 
WTRQECB  =  0 
(e.g.,  WRTQECB  is   at  R3DRQECB+4) 

After  G8MTRY  call,  but  before  any  subtask  2701  requests: 

Parmlist  for  subtask  Subtask   (within  G8ENTRY) 

+0      A(SUBTECB)  +0     SUBTECB  =   0    (for  G80PERAT 

+k     A(RDRQECB)  +k     A( RDRQECB )      HALT  notice) 

+8     A( STRING) 

G80PERAT 

RDRQECB  =  0 
WTRQECB  =   0 

Figure  16.      G80PERAT/Subtask  Linkage    (Part  1  of  3) 
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After  subtask  request  for  2701  read  (G8READ) : 
Parmlist  for  subtask  Subtask 


(same  as  above) 

G80PERAT 

RDRQECB  =  A(  INECB) 
WTRQECB  =  0 

(subtask  read  request  pending) 


(same  as   above) 

Record  Request  Block  1 

+0  INECB  =  0 

+k  A(INBUF) 

+8  (reserved) 

+10  Byte  length  of  INBUF 

INBUF  (subtask  supplied  area) 


After  2701  read  complete 

Parmlist  for  subtask 

(same  as  above) 

G80PERAT 

RDRQECB  =  0 
WTRQECB  =  0 

(subtask  read  request  cleared) 


Subtask 

(same  as  above) 

Record  Request  Block  1 

+0  INECB  =  return  code 
+k 

(same  as  above) 
+10 

INBUF* 

+0  console  number  (00N0) 

+2  record  type  (XXXX) 

+h     record  len  (PDP-8  -words  -l) 

+6 

Data 
+n 


*  All  input  in  the  unpacked  PDP-8  format 

(e.g.,  00XXXXXX00XXXXXX  =  one  12-bit  PDP-8  word) 


Figure  l6.   (Part  2  of  3) 


6k 


After  subtask  request  for  2T01  write    (G8WRITE) 


Parmlist   for  subtask 

(same  as  above) 

G80PERAT 

RDRQECB  =  0 
WTRQECB  =  A(0UTECB) 


(subtask  write   request  pending) 


Subtask 

(same  as   above) 

Record  Request  Block  2 

+0  0UTECB  =  0 

+k  A(0UTBUF) 

+8  (reserved) 

+10  Byte  length  of  0UTBUF 

0UTBUF* 

+0  console  number  (OOHO) 

+2  record  type  (XXXX) 

+k     record  len  (PDP-8  words  -l) 

+6 

Data 
+n 


*     All  output  in  unpacked  PDP-8  format. 


After  2701  write  complete: 

Parmlist  for  subtask 

(same  as  above) 

G80PERAT 

RDRQECB  =  0 
WTRQECB  =  0 

(subtask  write  request  cleared) 


Subtask 

(same  as  above) 

Record  Request  Block  2 

+0     0UTECB  =  return   code 
+k 

(same  as   above) 
+10 

0UTBUF 

(same   as   above) 


Figure  l6.      (Part  3  of  3) 
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START 


SAVE  INPUT 
PARM  STRING. 
G8ENTRY  CALL. 
INITIALIZE 


MAINTAIN 
OUTSTANDING 
READ  REQUEST 
TO  SPACT 


M    MAINWAIT 


AWAIT  AN 
EVENT 


(Event  occurred) 

®     ©     ® 

2701   2701  Other 
Read   Write 


SET  LOOP 
TO 

TEST 
TERMINALS 


Figure  17.      SPACT  Flow  of  Control    (Part   1  of  7) 


WT0 

WITH 

MESSAGE 


NO 


NO 


WT0 

WITH  MESSAGE 

CLEANUP 


ys\ 


POST 

TERMINAL 
WITH  RECORD 
ADDRESS 


*© 


\PROGRAM     / 
RtSiNING/ 


ADD  RECORD 
TO  INPUT 
QUEUE 


*© 


NO 


CLEANUP 

(FLUSH 

RECORD) 


*© 


Figure   IT-      (Part   2   of  7) 
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ADD  RECORD 
TO  OUTPUT 
QUEUE 


YES 


START  A  PART 
1  WRITE  ON 
FIRST  RECORD 
IN  OUTPUT  QUEJE 
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MARK  TERMINAI 
HAVING  A  REAI 
REQUEST 
OUTSTANDING 


ADD  RECORD 
TO  OUTPUT 
QUEUE 


DELINK 
RECORD 
FROM 
QUEUE 


RA 


® 


*© 


0 

_L_ 


PURGE  ANY   RECORDS 
IN  INPUT  OR  OUTPUT 
QUEUES   FOR  THIS 
TERMINAL   (ONLY 
INPUT. RECORDS   ARE 
FREEMAINed) 


DETACH   TERMINAL 
SUBPROGRAM  AND 
FETCH  OS 
COMPLETION   CODE 


(PREPARE  A  SINGL 
REPLY   FOR  THE 
TERMINAL    (WTC0N) 


Figure  17 .   (Part  3  of  7) 


© 

_L 


LOAD 

LOGGON 

DIRECTORY 


2 
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SET  LOOP 
TO  TEST 
TERMINALS 


YES 


SETUP  ACCOUNT- 
ING AND  TERM- 
INAL CONTROL 
SET   LOGGED  IE 


NO 


SET 

"ILLEGAL 
COMMAND"  MSG 


SET 

"READY" 

MESSAGE 


DELETE 

THE 

DIRECTORY 


SEND  MES- 
SAGE TO  THE: 
TERMINAL 
(WTC0N) 


SET  SAFETY 
TIMER, POST 
PROGRAM  TO 
HALT 


TIMER  INTERRUPT  OR 
PROGRAM  HALTED,  SO 
CANCEL  TIMER. DETACH 
TASK. PURGE  INPUT 
AND  OUTPUT  QUEUES 
FOR  THIS  TERMINAL. 


Exit  to  0S/36O 


© 


Figure  IT.   (Part  1*  of  7) 


YES 


WT0  WITH 
MESSAGE. PASS 
COMPLETION 
CODE  h   OR  8 
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C3 


WAS  OUTPUT 
BROKEN;  LEAVE 
RECORD  ON 
OUTPUT  QUEUE 


-Wmr  j 


PASS 

COMPLETION 
CODE   0    (0K) 


■©— 


PURGE  RECORD 
FROM  QUEUE 


FREEMAIN 
THE  REPLY 
AREA 


YES 


START  A  PART 
2  WRITE   ON 
FIRST   RECORD 
IN   OUTPUT  QUAUE 


*/mT\ 


NO 


POST  TERMINAL 
WITH   CODE 
IF  STILL 
RUNNING 


— © 


WT0  WITH 
MESSAGE 
PASS  CODE  h 


(ABEND  SINCE 
"BROKEN"  SHOULD 
NEVER  HAPPEN  ON 
PART  2  WRITE) 


Figure  IT.   (Part  5  of  7) 
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[NT  Dl 
).F  TERMINALS 
?R0GI 


r>c 


jT  tj 

TERMINALS 
J>R0GRAM> 


DETACH 
TERMINALS 
.PROGRAM. 

10 

Dart 
'terminal 

.PROGRAM 

[no 

jOGOUT 
'THE  TERMINi 


CSSAC 
■DR  ANO' 
.TERMINAL 


YES. 


DUMP 

OPEN  DUMP 
DATASET. SNAP 
PROGRAM.  CLOSE: 
DATASET 


HALT 


YES 


POST  HALT 
REQUEST   TO 
PROGRAM 

ZAP 


YES 


PURGE   RECORDS 
IN  QUEUES, 
THEN   DETACH 
PROGRAM 


Sname  PARM  k 


YES 


START  A 
PROGRAM  FOR 
THE   TERMINAL 


L0G0UT 


YES 


CLEANUP 
TERMINAL  CONI, 
SET  NOT 
LOGGED  ON 


YES 


Mnn-msg 

/SEND  "MSG" 
TO  SPECIFIED 
TERMINAL  nn 

.(WTC0N) 


'SMD 

"COMPLETE" 
MSG  TO  TERMI 
.(WTC0N) 


'SEND  "HALT 
REQUESTED" 
MSG  TO   TERMI)      i 
(WTC0N) 


fSEND  "TASK 
TERMINATED" 
MSG  TO  TEBMH":.-vr, 
(WTC0N) 


'SEND  "TASK 

STARTED" 

MSG   TO  TERMI. 
.(WTC0N) 


'SEND  "GOOD- 
BYE" MSG  TO 
TERMINAL 
(WTC0N ) 


Figure  IT-      (Part  6   of  7) 
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SEND  "ILLEGAL 
J  COMMAND"  MSGL_ 
\   TO  TERMINAL  P" 
\(WTC0N)     / 

DSPACT 


OPEN   DUMP 
YES J  DATASET.SNAP 
SPACT.  CLOSE 
DATASET 


AL 


OPEN  ACCNT 
DATASET, SEND 
INITIAL  MSG 


NO 


U! 


SEND  FINAL 
MSG, CLOSE 
DATASET 


fSEND  "SPACT 
DUMP  COMPLE1 
TO   TERMINAL 

,(¥TC0N) 


SEND   "ACCNT 
STARTED"  MSG] 
TO   TERMINAL 
(WTC0N) 


'SEND   "ACCNr 

STOPPED" 

MSG  TO 

TERMINAL 
t(WTC0N) 


\ 

TED" 


f         WTC0N         J — » 


GETMAIN  A  REPLY 
BUFFER; IF  NO 
SPACE  ,WT0. MOVE 
IN  MSG  AND 
TRANSLATE   FOR 
PDP-8 


(Return) 


Figure   17 .    (Part  7  of  7) 
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SPACT 


Subtask 


Parmlist  for  subtask 


+0 

+k 

+8 

U2 

u6 


( available ) 
A(user  work  area) 
A(XFILEOOl) 
A(log  user) 
A(parm  string) 


(user  must: 

1.  save  parmlist  address 

2.  set  XFTLE001  into  V-con 

3.  call  S8ENTRY 
before  anything  else) 


Parmstring 

2k  characters : 
parm  field 
(from  START  command) 


Loguser 

8  characters : 

user  logon  name 


Trmcntrl 


User  Work  Area  (ik  words) 


+0  0 


+k 

A(27O10PRQ) 

+8 

0 

+12 

0 

+1$ 

(+8,+12,+0) 

+28 

(+8.+0) 

+36 

(+12s+0) 

+kk 

0 

+kQ 

0 

+52 

0 

SPACT  ECB  for 
HALT  request 
2701  request  link 
2701  Read  done  ECB 
2701  Write  done  ECB 
S8WAIT  ECBLIST 
S8READ  ECBLIST 
S8WRITE  ECBLIST 
A(0THER) 

Register  2  save  wrd 
Addressability 
save  word 


+0     27O10PRQ:      READ  request  ECB 

+k  WRITE  request  ECB 

+8    A(User  work  area)  +8  0Pdone  ECB's 


Figure  18.      SPACT/User-Program  Linkage  After  S8ENTRY 
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Trmcntrl 

+0     Read  request  E£B:     P0STed  by  subtask  when  S8KEAD  issued. 
+k     Write  request  ECB:     P0STed  by  subtask  when  S8WRITE  issued. 
+8     A( Subtask  Op-completed  ECB's):      set  by  S8ENTRY.     ECB's  P0STed  by 

SPACT  as  appropriate. 
+12     Subtask  TCB:     Used  for  DETACH  and  DUMP;   if  zero,  no  subtask  running 

(Saved  after  ATTACH) 
+16     Subtask  End  ECB:     P0STed  by  0S  when  subtask  terminates   (this  ECB 

specified  during  ATTACH). 
+20     A(ACCNT):     A  (Ac  counting  Area)    for  this  terminal. 


Accnt 

+0  User  logon  string 

+8  Status  -word  one,      ,        _  , 
.,„  „.  .      ,  ,   }  record  counts,  funds,  etc. 
+12  Status  -word  two 


+16  Control  byte  (X'801  =  logged  on) 
+17  Data  logged  on 
+20  Time  logged  on 


Figure  19.   SPACT  Terminal  Control  Area  Detail 


■7* 
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APPENDIX  A 
Buffering  Control  Program   (ACID) 


77 

A  program  has  "been  developed  for  the  PDP-8/I  to  maintain  the 
storage  tube  terminals  that  are  attached  to  it.     Basically^  display  files 
are  read  out   of  the  PDP-8,  buffered  in  the  PDP-8 /I,   and  then  fed  to  the 
terminal.      In  the  other  direction,   joystick   (X,Y)    and  keyboard  text-lines 
input  by  a  user  at  a  terminal  are   sent  to  the  PDP-8.      A  chained  buffering 
scheme  with  storage  allocation/deallocation  is  used,   so  that  all  attached 
terminals   can  be   sent  display  data  simultaneously.      In  addition,  the  line 
that  a  user  types   is   refresh  displayed  in  write-through   (non-storing) 
mode,   enabling  typed  corrections  to   appear  immediately  and  in  place. 
Moreover,   since  the  line  is  not  stored  in  this   "line  buffer"   area,   the 
display  need  not  be  erased  and  regenerated  for  the  user  to  type  his  next 
line  in  the  buffer. 

Communication  between  the  two   CPU's   is   accomplished  with  two 
software   flag  words  in  the  PDP-8,   one  for  Input    (terminal  to_  PDP-8),   and 
one   for  Output    ( PDP-8  to_  terminal) . 

(TFLAG8)   Input:   1.      zero  means  no  input  yet. 

2.  set  to  nonzero  by  PDP-8/I  means   input  ready 
to  be  processed  by  PDP-8. 

3.  set  to   zero  by  PDP-8  means  processing  of  input 
now  completed;   ready  for  more;   go  to  state   l) . 

(DFLAG8)   Output :1.      zero  means  no  output  yet. 

2.  set  to  nonzero  by  PDP-8  means  output  ready  to 
be  processed  by  PDP-8 /I. 

3.  set  to   zero  by  PDP-8/I  means  processing  of  output 
now  completed;   ready  for  more;   go  to   state  l). 

TFLAG8  is  located  at  2000  in  bank  3   (GLBANK),  while  DFLAG8  is   at   50  in 
bank  3.      TFLAG8  is   the   first  word  of  a  kO  word  buffer;   DFLAG8  is  the  first 
of  three  words. 

For  the   following  discussions,  bits   in  a  word  are  numbered  most 
significant   (left)    to  least  significant   (right),   0  to  11. 
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Flag  Designations 

A.  TFLAG8:  bit  0       (input  ready  when  on) 

bit  1-8  (interrupt  character) 

0  =  carriage  return  (text  line) 

1-7  =  joystick  hit  (X,Y) 

8-255  =  function  option  (currently  unspecified) 

bit  9-H  (console  number) 

Rest  of  Buffer: 

keyboard  line  Joystick  hit 

word  2  number  of  characters  Y  (10  bits) 

(max  currently  allowed  =  72) 

word  3   (unused)  X  (10  bits) 

word  U- UO 

six  bit  packed  ascii  (unused) 

characters  with  last 
set  to  a  "blank"  if 
count  (word  2)  is  odd 

B.  DFLA.G8:  bit  0       (output  ready  when  on) 

(function) 

=  enable   console 

=  input  text  line  to   console's 
text -line   display  buffer 

=  process   display  file  for 
console    (e.g. ,   display) 


bit 

0 

bit 

1- 

1 

2 

3 

-5 

k- 

-31 

(unspecified) 


Display  File 


The  display  file  input  by  the  PDP-8/I  is   in  the  DEC  338  file 
format    [l7]»   except  for  the  use   of  the   "spare"  mode  7-      This  mode   is   used 
to  provide   special  display  instructions  to  the  PDP-8/I.      Each  bit    (of  bits 
3-11)   represents  an  option  and  the  bits  are   "executed"   right  to   left, 
so   "microprogramming"   of  options   is  possible.      (option  is    "on"   if  bit  is   a 
"1"). 
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bit   11  -  disable  output  of  terminal  to  PDP-8 
bit   10  -  erase  screen 
bit  9     -  add  frame  lines  to  display- 
bit  8     -  enable  output  of  terminal  to  PDP-8 
bit  7     -  end  of  display  file  segment   (e.g.,    another 

file  -will  be  output  soon   for  this  terminal;    do 

not   release  buffers) 
bit  6     -   (same   as  bit   7   currently) 
bit   3,   k,   5   currently  unspecified 

Terminal   Character  Set 

For  the   following,    "f  represents   a  control  character  and  - 
means   the  indicated  character  is   ignored.      All  numbers   are  octal. 


typed  on 

keyboard 

« 

(2) 

-E 

(5) 

W 

(6) 

«AC 

(10) 

fEAB 

(11) 

« 

(13) 

CR 

(15) 

Fl 

(21) 

F2 

(22) 

F3 

(23) 

Fh 

(2k) 

F5 

(3k) 

F6 

(35) 

echoed  in  line  buffer  as 

move  text -line   cursor  to 
(Mtlct)   1st  line   character 

Mtlct  last   line   character 

Mtlct  next  right   character 

Mtlct  next  left   character 

Mtlct  6th  right   character 

Kill  character  line 

Mtlct   1st  line   character,    reset 


sent  to  PDP-8  as 

Not  sent 
Not  sent 
Not  sent 
Not  sent 
Not  sent 
Not  sent 
Send  line 
Joystick  hit 
Joystick  hit 
Joystick  hit 
Joystick  hit 
Joystick  hit 
Joystick  hit 


( continued) 
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space 

(4p) 

t 

(41) 

tt 

(42) 

# 

(43) 

$ 

(44) 

% 

(45) 

& 

(46) 

i 

(47) 

( 

(50) 

) 

(51) 

* 

(52) 

+ 

(53) 

» 

(54) 

- 

(55) 

• 

(56) 

/ 

(57) 

0 

(60) 

•   •   • 

9 

(71) 

• 

(72) 

5 

(73) 

< 

(.74) 

= 

(75) 

> 

(76) 

1 

(77) 

A 

(101) 

space  40 

!  41 

42 

*  43 
$  44 

*  45 
&  46 

47 
(  50 

)  51 

*  52 
+  53 

54 
55 
56 

/  57 

o  6o 

•  •  •  •  •  • 

9  71 

:  72 

;  73 

<  74 

75 

76 

?  77 

A  01 

(continued) 
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z  (132)  z  32 

[  (133)  (  50 

^  (134)  -,  36 

1  (135)  )  51 

(137)  35  but  NOT  sent; 

can  only  come 
FEOM  the  PDP-8 

a        (lUl)  a  01 

z  (172)  z  32 

{  (173)  (  50 

I  (17^)  I  34 

}  (175)  )  51 

-1  (176)  -!  36 

Note  that  0,   33,   and  37  are  never  sent  to  the  PDP-8   since  these  mean 
carriage -re turn,   line-feed,   and  escape,   respectively,  when  they  appear 
in  a  display  file.      In  addition,   35    (underscore)   is  never  sent  to  the 
PDP-8.     All  possible  keyboard  characters  not  mentioned  above  explicitly 
are  ignored  by  ACID. 
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APPENDIX  B 
System  Generation  and  IPL 
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1.      Local  System  Generation 

Use  a  PDP-8  Disk  Monitor  System   [18]  to  assemble  and  save  the 
programs  as  shown  "below.      PEND  contains  just   a  $  to  mark  the  end  of 
PAID  input.      PSEQ  contains   a  large  number  of  equates;   this   facilitates 
symbolic  references  to   all  control  areas  and  "between  separately 
assembled  programs. 

GLASP:   GMN2,PEND 

.SAVE  GMN2! 30000-35777 ;30203 

IR:   PSEQ, DISK, DIRC,SVIR,PSIR,PEND 

.SAVE  GLJR! 26000-27777 ;26l  1+3  (moved  to  GLBANK  during  system  IPL) 
.SAVE  PSIR! 3^000-35777; 30150  (segment  37) 

GUTS :   UTEQ,GTS1 ,DSM1 ,DSM2 ,DSM3 ,DSMU ,DSM5 ,IRRE ,GT32 ,2701 ,DPU1 ,PRIN, 
DPU2,DSM6,PEMD 

.SAVE  GUTS! 10000-17777 ;100U3 

Segments :   PSEQ ,name , PEND 

.SAVE  name  13^000-35777; 30150  (segments  0-36) 

ACID :   ACID 

.SAVE  ACID: 0-3777 ;200 

A  system  load  tape  is  then  built  from  these  modules  using  WL.0D  as 
described  below.      GL0AD  and  GEXIT  for  loading  the  system,   and  the  library, 
are   described  in    [7]. 


WL0D 


a.  Mount  the  tape  to  be  modified  on  Unit  k,   write  enabled. 

b.  Start  execution  of  WL0D  from  the  DMS. 

c.  Type  the  name  of  the  contiguously  saved  program  to  be 
written  on  the  tape . 

d.  Type  the  octal  number  associating  the  program  with  an 
area  on  the  tape.   See  following  chart. 

e.  Go  to  C)  and  repeat  until  all  desired  programs  written; 
then  type  control  C  to  exit  to  DMS.   Unload  tape. 


Qk 


Data 


WL0D  No.  Blocks  on  Load  Tape  Blocks  on  Disk* 


DECtape  System** 

- 

0-3TT 

— 

Program  Segments 

0-37+ 

UOO-TTT 

llUO-1537 

GLASP 

1+0 

1000-1021* 

- 

GLIR 

1*1 

1025-1031* 

- 

GUTS 

1*2 

1035 -107U 

- 

ACID 

1*3 

1075-Hll* 

'■    - 

Data 

Blocks 

on  Library  Tape 

Blocks   on  Disk* 

Core   copy  of  free 
block  list 
( 6h  words ) 

0 

—(from  GLIR) 

Control  Pointers 
(6  -words) 

0 

—  (from  GLIR) 

Free  "block  list 

1-20 

151*0-1557 

Directory  blocks 

21-120 

1560-1657 

Library  blocks 

121-2637 

1660-U377 

One  other  utility  is  available  for  tape  modification.  PEEPER 
allows  octal  alteration  (in  a  manner  similar  to  XOD  or  HELP)  of  arbitrary 
tape  blocks. 


PEEPER 


a. 


b. 


Start  execution  of  PEEPER  form  the  DECtape  system  (e.g.  , 
on  a  GRASS  load  tape). 
In  response  to  "PGM#:",  respond  with 

1.   a  WL0D  number  (0-1*3)  if  a  GRASS  program  modification 
is  desired,  or 


* Consult  [6]. 

+ 

Corresponds  to  program  segment  numbers . 

**  Includes:   X0D,  XDUP,  XFILE,  etc.,  as  well  as  GL0AD,  GEXIT,  PEEPER 
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2.      a  DECtape  -unit  number   (D0-D7)   if  an  arbitrary  tape 
"block  is   desired.      In  this  latter  case,   an  octal 
block  number  also  must  be  specified  when  "BLK#:" 
is   requested. 

c.  The  program  (l)    or  tape  block   (2)  will  be  read  into  core. 

d.  Now  proceed  as  with  X0D  to  examine   and  change  locations. 
Obviously,  locations   outside  the  range  of  the  requested 
program  or  tape  block   (0-177)    cannot  be  modified. 

e.  Typing  control-P  or  control-C  will  write  out  any 
changes  made ;  the  former  will  then  cause  PEEPER  to 
restart  at  step  b),  while  the  latter  causes  return  to 
the  monitor. 

2.      Remote  System  Generation 

The  remote  system  makes  use  of  three  OS/360  data  sets.      A 
macro  library,   used  only  during  the  assembly  of  system  or  user  programs, 
contains   the  following: 


P8 -macros 

P8I0 

P80PRS 

P80PRSX 

P8RCCW 

P8RETRY 

P8WAIT 

P8WCCW 

G8-macros 

G8EWTRY 
G8READ 
G8WAIT 
G8WRITE 


S8-macros 

XFile  macros 

S8DATA 

XAPPEND 

S8ENTRY 

XCL0SE 

S8READ 

XDELETE 

S8SETUP 

XDESTR0Y 

S8WAIT 

XINIT 

S8WRITE 

XLINK 

XLIST 

X0PEN 

Utility  macros 

XREAD 

PAIS 

XREADDIR 

PBR 

XREADIRS 

PLR 

XREAOT 

PI£T 

XREADS 

PSTR 

XREWIND 

XTERM 

XWRITE 

LSD 

ITEM   ^ 

GL0BAL1  1 

.  Simulation  and 

GL0BAL2  1 

Modeling  Package 

ELIM    1 

C0MP1   | 

SPARSE 
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Two  other  data  sets  are  active  at  execution.   The  first  is  the 
library  data  set  used  by  XFILE.   This  contains  the  remote  directory, 
space  allocation  bit  map,  and  library  blocks.   The  second  is  a  load 
module  library  containing  the  system  programs  and  all  user  programs 
that  run  under  it.  Modules  included  are: 

System  User 

G80PEFAT 

SPACT 

GIDS 

XFILE 

C0MMUNE 

BATCH 

P0T 


Some  other  modules  in  this  data  set  are  used  during  linkediting: 

CALLER 

S8SETUP 

MY#FI0CS 

Note  that  all  software  runs  in  HIARCHY=1  and  is  system  independent  for 
release  18  and  above  of  0S/36O. 

Sample  JCB 

1.   Create  top  monitor  level 

//  EXEC  ASM,MACFILE='MACR0S' 

(G80PERAT  Source) 
//  EXEC  LKED,LIBFILE=,L0ADM0DS' ,PARM='LIST,      X 
//       XREF^T^IAR1 

HIARCHY  1,G80PERAT 

NAME  G80PERAT(R) 
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2.  Create  a  typical  lower  level  or  user  module 

//  EXEC  ASM... 

(source) 
//  EXEC   LKED,PARM='  LIST,  XREF,  LET,  RENT' 

NAME  XX(R) 

(The  above  module  is   loaded  by  a  higher  level  module    iito  the  proper 
storage;  hence,  HIARCHY  parameters  need  not  be  used). 

3.  Create   a  typical  user  module   containing  CALLER  and  special 
FORTRAN  I/O 

//     EXEC     ASM  or  F0RT. . . 
(source) 

//      EXEC     LKED,PARM=... 
ENTRY   CALLER 
INCLUDE  SYSLIB(MY#FI0CS) 
NAME      XX(R) 

(Consult    [8]). 


h.      Run   the  monitor  system 

//J0BLIB    DD    DSN=L0ADM0DS,DISP=SHR 

//GRASS  EXEC  PGM=G80PERAT, 

//  REGI0N=(12K,25OK), 

//  PARM='S   SPACT' 

//SYSUDUMP  DD  SYS0UT=A 

//SYSPRINT  DD  SYS0UT=A 

//PDP8DD  DD  UNIT=021' 

//DISK  DD  DSN=GRAPHLIB,DISP=0LD 

//FT05F001  DD  DUMMY 

//FT06F001  DD  SYS0UT=A 

//FT0TF001   DD  DUMMY 
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5 .      Run  the  P0T  plotting  package 

//J0BLIB      DD     DSN=L0ADM0D3 ,DISP=SHR 

//P0T  EXEC   CALC0MP, 

//  REGI0N=(1T5K,3OK), 

//  PARM='EP=P0T,PL=3O9TIME=6.OO, 

/ /G0 . SYSLM0D  DD  DSN=L0ADM0DS , DISP=SHR 

//G0.SYSPRINT  DD  SYS0UT=A 

//G0.SYSUDUMP  DD  SYS0UT=A 

//G0.DISK  DD  DSN=GRAPHLIB ,DISP=0LD 

//G0.FTO5FOO1  DD  DUMMY 

//G0.SYSIN  DD  * 

( input  cards ) 


6.  Run  the  BATCH  test  module 
(Consult  [9]). 

7.  Save  the  remote  library  on  tape 

//SAVE  EXEC  PGM=IEBGENER 

//SYSPRINT  DD  SYS0UT=A 

//3YSUT1   DD  DSN=GRAPHLIB,DISP=SHR, 

//  DCB=(BLKSIZE=T93,LRECL=T93,RECFM=F) 

//SYSUT2      DD     DSN=SAV0NTAPsUNIT=TAPE,LABEL=i, 

//     DISP=dTEW,KEEP),V0L=SER=tapeids 

//     DCB=(BLKSIZE=T93,LRECL=T93,RECFM=F) 

8.  Reload  the   remote   library  from  tape 

//REL0AD  EXEC  PGM=IEBGENER 

//SYSPRINT     DD     SYS0UT=A 

/ /SYSUT1      DD     DSN=SAV0NTAP , UNIT=TAPE ,LABEL=i , 

//     DISP=0LDsV0L=SER=tapeid, 

//      DCB=(BLKSIZE=T93,LRECL=793,RECFM=F) 

//SYSUT2      DD     DSN=GRAPHLIB,DISP=0LD, 

//     DCB=(BLKSIZE=793,LRECL=793,RECFM=F) 
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APPENDIX  C 
GLASP  Routines — Detail 


90 


INTHND  ' 

Entered  via  location  2,  "bank  0,  with  standard  DEC  interrupt 
procedure.   First  tests  disk  done  and  immediately  goes  to  IR  entry  point 
BSRTRN  (6000)  if  found.  Next  tests  DPU  software  flags  and  goes  to 
DPUINR  if  (l)  DPU  input  not  currently  being  processed  (DPUINP=0)  and 
(2)  new  DPU  input  is  in  "buffer  (DPUINF  N0T  0).   Clock  flag  is  tested 
next;  if  on,  all  timer  queue  elements  are  incremented  with  INTHN2 
(CLKQR).   If  INTHN2  finds  any  terminals  to  be  interrupted,  CLKQR3  is 
used  to  set  2010  pending  for  each  such  terminal.   Note  that  the  interrupt 
handler  is  N0T  exited  during  this  processing  (as  opposed  to  calls  to 
BSRTRN  and  DPUINR) .   INTHN2  returns  to  the  mainstream  of  INTHND  processing 
at  INTHN3,  but  after  ELAPC  is  called  to  update  the  time  display  area  for 
the  system  message  line.   INTHN3  is  the  final  phase  of  interrupt 
processing;  two  tables  are  used  to  test  all  remaining  device  flags.   The 
first  table  contains  the  I0T,  while  the  second  contains  the  appropriate 
address  in  bank  1  (UTBANK)  for  device  handling  if  the  associated  I0T 
"skips"  (flag  on).   Note  that  undesirable  device  flags  can  be  ignored 
simply  by  using  a  "clear"  I0T  instead  of  a  "skip"  I0T  in  the  first  table. 
The  last  entry  in  the  first  table  is  a  jump  to  the  WAIT  routine;  hence, 
if  only  the  clock  or  an  undesired  device  flag  caused  the  interrupt,  GLASP 
returns  to  the  wait  state. 

FR2701 

Entered  from  INTHND  if  "2701  ready  to  send  to  PDP-8"  was  found. 
Uses  preset  data  to  begin  the  read  operation,  then  goes  to  WAIT.   When  the 
operation  is  complete,  FD2701  is  entered  from  INTHND.   This  routine  tests 
for  and  begins  a  retry  if  necessary  (data  error,  etc.).   If  the  record  was 
correct,  the  routine  goes  to  FN2701  to  check  if  it  was  the  first  or  second 
part  of  a  record.   The  I2701P  flag  is  set  accordingly.   If  the  record  was 
a  second  part,  FE2701  is  entered  to  reset  the  system  for  another  first  part; 
GLASP  is  then  called  via  0PD0NE  (e.g.,  2701  completion  service  is  finished). 
If  the  record  is  a  first  part,  I0T  information  is  preset  for  use  by  FR2701 
in  case  a  second  part  is  expected.   Then  the  record  type  is  tested  for  a 
monitor-monitor  internal  command.   If  such  is  found,  the  appropriate 
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internal  routine  is  called;  if  not  found,  the  record  is  for  a  terminal, 
so  FC2T01  is  called.   This  routine  calls  F2701W  in  GLBANK.   F2T01W  tests 
the  status  of  the  terminal  with  T0LAC  (see  "below).   If  the  terminal  is 
offline,  FC2701  is  told  to  flush  the  record  internally  and  return  to  WAIT. 
If  the  terminal  is  online  but  inactive,  FC2701  flushes  the  record,  but 
causes  the  subsequent  execution  of  segment  0  (CALLER)  for  the  terminal 
(via  SYSCTL) .   If  the  terminal  is  active,  2001  is  set  pending  for  the 
terminal  and  lockout  checking  is  performed.   Finally,  F2701W  goes  to  WAIT. 

The  only  internal  monitor-monitor  command  currently  in  use  is 
indicated  by  type=7770.   This  means  the  remote  monitor  is  up;  an  "H"  is 
printed  on  the  operator's  TTY  printer  and  an  internal  flag  Is  cleared 
(see  0PKB). 

0PKB 

Entered  from  INTEND  if  a  character  on  operator's  TTY  keyboard 
is  sensed.   All  commands  are  currently  one  character  long  and  execute 
immediately.   The  input  character  plus  a  carriage-return,  line  feed  sequence 
are  sent  to  the  TTY  printer.   If  the  command  is  unrecognized,  a  "?"  is 
printed.   Current  commands  are  : 

!  =  ignore  segment  2701  output  operations  (e.g.  ,  an  internal 
flag  (Q2701P)  is  set  so  the  whole  operation  proceeds  as 
normal  except  that  no  transmission  takes  place).   Used 
when  the  remote  monitor  is  not  up. 

"  =  the  internal  flag  is  cleared  so  2701  output  operations  will 
indeed  transmit  data.   Used  when  GLASP  is  restarted  and 
remote  monitor  is  already  up. 

Operator  device  input  to  a  terminal  is  not  currently  supported. 

DPUINR 

Entered  from  INTEND  if  DPU  input  ready  to  be  processed.   Calls 
PICSEG  to  test  input  data  type;  for  keyboard  lines  PICSEG  tests  the 
terminal's  filter  word  (+36  console  vector),  while  for  joystick  hits 
PICSEG  first  determines  the  screen  segment  hit  and  then  tests  the  appropriate 
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filter  word.      In  either  case.,   an  accept/not-accept  code  is  returned  to 
DPUINR.      T0LAC  is  then  called  to  test  the  terminal's   status.      If  the 
terminal  is  offline,   the  input  will  be  flushed  internally;   control  is 
returned  to  WAIT.      If  the  terminal  is  online  but  inactive,   the  input 
is   flushed  but  segment  0    (CALLER)   is  started  on  the  terminal  via  a  call  to 
SYSCTL.      If  the  terminal  is  active  and  the  code  from  PICSEG  was   "accept," 
20()1+  is  set  pending;   control  returns  to  WAIT. 

CLKQR 

Entered  during  INTEND  processing  of  clock  interrupts  to 
increment  timer  queue  elements.   If  a  timed  interval  reaches  zero  for 
an  active  terminal  that  has  "accept  timer  input"  set,  CLKQR3  is  used  to 
set  2010  pending  for  that  terminal.  After  all  terminals  are  checked, 
control  returns  to  INTHN3. 

R0UTX 

Entered  via  JMS   from  segments  or  system  to  begin  a  service  for 
the  current  terminal.      The  desired  service  group  is  indicated  by  the 
number  in  the  ACC  at  entry.      Necessary  parameters  for  the  service  are 
assumed  already  in  SVPRM1-8  in  GLBANK;   these  are   saved  in  the   console 
vector.      The  caller's  restart  address   and  bank  are  also  saved  in  the 
console  vector.      Availability  of  the  desired  service  is  then  tested  via 
R0UTXR.      If  the  service   is  not   free,   R0UTX  stores  the  service  group 
number  in  the   console  vector   (thus   indicating  that  a  request  is  pending) 
and  goes  to  WAIT.      If  the  service  is   free,   R0UTXR  copies  the  parameters  to 
SVPRM1-8  in  UTBANK,   sets  the   service  request  word  in  the  console  vector 
to  -1   (terminal  busy,   service  being  processed),   sets  the  service  busy   (with 
the  address  of  the   caller's   console  vector),   and  jumps  to  the  R0UTX  entry 
point  of  the   routine  in  UTBANK.     The  console  vector  address  is  passed  to 
the  UTBANK  routine  in  the  ACC. 


93 


TSTQUE 

Entered  from  WAIT  to  test  all  "pending"  conditions  (e.g.  device 
input  and  service  requests).  Each  console  vector  is  tested;  if  the  busy- 
flag  is  on  (request  word  =  -l) ,  no  action  is  taken.  If  the  flag  is  >  0 
(e.g.,  a  service  request  is  pending),  R0UTXR  is  called  to  try  to  start  the 
request.  A  successful  start  by  R0UTXR  obviously  terminates  TSTQUE 
processing.   Otherwise,  testing  the  next  terminal  follows  the  R0UTXR  call. 
If  the  flag  is  0  (e.g.,  terminal  free  (not  busy)),  the  device  input 
pending  bits  are  tested.   If  a  bit  is  found  on,  the  corresponding  device 
routine  address  is  checked;  zero  means  ignore,  nonzero  means  accept. 
TSTQUE  has  a  list  of  "ignore"  entry  point  addresses,  one  for  each  device. 
The  appropriate  routine  is  called,  and  the  input  is  internally  flushed. 
In  the  case  of  "accept,"  the  nonzero  flag  is  the  entry  address;  the 
current  terminal  segment  is  started  via  XCTLS  (TSTQUE  processing  is 
terminated).   If  no  action  is  needed  or  none  can  be  initiated  by  TSTQUE, 
control  returns  to  WAIT. 

WAIT 

Entered  whenever  processing  must  be  suspended  pending  completion 
or  occurrence  of  an  operation  or  event.  A  group  of  priority  flags  are 
tested  first;  this  enables  certain  critical  internal  processes  to  ensure 
serial  use  of  particular  resources.   If  a  priority  flag  is  set  (not  zero), 
the  appropriate  resource  busy  flag  is  tested.  A  zero  (not  busy)  resource 
flag  causes  control  to  be  passed  to  the  routine  address  specified  by  the 
priority  flag.   The  called  routine  is  responsible  for  clearing  and 
setting  the  priority  flag,  as  necessary.  WAIT  processing  is  at  an  end. 
If  no  action  is  taken  during  priority  flag  testing,  TSTQUE  is  then  called 
to  schedule  pending  requests  or  input  if  possible.   If  TSTQUE  returns  to 
WAIT,  the  interrupt  is  turned  on  (I0N)  and  the  program  loops  until  an 
interrupt  occurs  (e.g.,  a  device  or  the  clock).   This  is  the  one  and  only 
idle  state  for  the  entire  local  system. 
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0PD0NE 

Entered  from  a  completing  service  routine  or  from  XCTL  (see 
below).  As  soon  as  possible,  the  segment  for  the  indicated  terminal 
is  restarted  at  the  atdress  (and  bank)  stored  in  the  console  vector.  The 
ACC  tells  0PD0NE  which  service  is  completing  (0  for  XCTL) ;  the  terminal 
to  be  restarted  is  indicated  by  the  contents  of  the  service's  busy  flag. 
This  word  is  used  to  reset  CURC0N  (current  console),  and  the  service 
flag  is  set  to  zero  (free).   TSTPCR  is  then  called  to  check  if  the  segment 
needed  for  this  terminal  is  the  one  currently  in  core.   If  it  is,  the 
SVPRM  save  area  in  the  console  vector  is  copied  into  SVPRM1-8  in  GLBANK;  then 
the  return  information  is  extracted.   Control  is  passed  to  the  restart 
location;  0PD0NE  processing  terminates.   If  the  required  segment  is  not 
in  core,  the  console  vector  address  for  this  terminal  is  placed  in  a  stack, 
and  a  priority  call  to  WAIT  is  made  (GETPl).  0PD0NE  processing  terminates 
temporarily. 

As  soon  as  the  disk  busy  flag  is  clear,  the  priority  flag 
scan  in  WAIT  will  transfer  control  back  to  0PD0NE.   The  last  entry  on 
the  console  address  stack  is  extracted,  and,  if  the  stack  is  now  empty, 
the  priority  request  is  cleared.   0PD0NE  now  calls  FETPA  to  load  the 
segment  needed  by  the  indicated  terminal  from  the  disk.  When  the  segment 
is  in  core,  0PD0NE  processing  proceeds  as  above.  Note  that  the  disk  busy 
flag  is  made  "busy"  when  EETPA  is  called;  hence,  WAIT  will  never  make  a 
priority  return  to  0PD0NE  while  a  segment  is  being  fetched. 

RELESE 

Entered  from  a  segment  when  current  processing  of  input  has  been 
completed.   The  terminal  (e.g.,  segment)  is  now  ready  (and  waiting)  for 
more  input.   RELESE  sets  the  request  word  to  zero  (free),  and  then  performs 
a  safety  "unfix"  via  MNIMF  for  all  standard,  nonstandard,  and  work  blocks 
associated  with  the  terminal.   Control  is  then  passed  to  WAIT. 
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XCTL 


Entered  to  begin  execution  of  a  different  segment  for  the 
current  console.   The  call  is: 

TAD  X 

JMS  I  XXCTL 

ADDR 

ID 

ADDR  gives  the  new  entry  point;  ID  (0-37)  gives,  the  new  segment  number. 
If  X  <  0,  the  SVPRM1-8  area  in  GLBANK  is  saved  in  the  console  vector 
before  the  operation  commences;  otherwise,  the  GLBAHK  copy  is  lost 
(before  execution  of  the  new  segment  begins,  the  console  vector  SVPRM1-8 
area  is  copied  to  the  GLBANK  area).  XCTL  simply  resets  the  locations 
used  by  R0UTX  and  calls  0PD0NE  with  ACC  =0.   If  ID  =  -1,  the  segment  is 
not  changed;  the  current  segment  is  entered  at  the  new  location.   One 
routine  mentioned  previously,  SYSCTL,  is  merely  a  call  to  XCTL  that 
specifies  CALLER  as  the  segment  and  ^000  as  the  entry  address. 

GLMSGA 

Entered  to  take   an  indicative  text-line   from  the  2701  and  display 
it   on  the  appropriate  terminal.      The   call  Is  a  JMP  to  GLMSGA  with  SVPRM3  =  Y 
and  SVPRM1+  =  X  giving  the   screen  position  of  the  line.      GLMSGA  returns  to 
RELESE  when  finished,  not  to  the  segment.      The  appropriate  call;  is  made  to 
R0UTX   (service  h)   to   complete  2701  processing.      If  the  input   is  not  of 
type  =  0,  the  data  is   flushed,   and  a  message  is   sent  to  the  terminal.      If 
the  input  is  type  =  0,  the  input  appears  on  the  terminal.      PCW0RK  is  used 
to  buffer  the   input;   the  2701  is    cleared;    and  then  the  DPU  is   enqueued. 
When  DPU  processing  is   complete,   the  word  at  PCW0RK  is   set  =  0,    and  RELESE 
is   called.      Since   some  segments    (for  example  the  text  editor  in  GUTl)   use 
PCW0RK  for  user  area  message   lines ,   setting  PCW0RK  =  0  will  prevent  a 
DPU  error  when  such  a  segment  is   re-entered  following  GLMSGA  processing 
(c.f.    the  text  editor  and  GREGPl).      Note  that   a  segment   can  enter  this 
routine   at   a  point   GLMSG  for  displaying  a  line   already  in  PCW0RK. 
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DPUDIN 

Entered  to  transfer  control  to  the  proper  routine  after  DPU 
input  marked  pending.   Segments  desiring  to  accept  DPU  input  should 
always  use  DPUDIN  as  the  device  entry  address  (+22  in  the  console  vector) . 
TSTQUE  will  transfer  control  to  DPUDIN  as  appropriate;  DPUDIN  uses 
information  saved  by  PICSEG  to  transfer  control  to  the  proper  screen 
segment  or  keyboard  line  routine.   DPUDIN  always  moves  words  at  DPUINF+1 
and  DPUINF+2  into  +112  and  +113  of  the  PCB.   For  joystick  DPU  input, 
these  are  the  Y  and  X  hit  coordinates. 

GREGEN 

Entered  to  automatically  redisplay  the  standard  blocks  of  the 
current  picture.   The  routine  assumes  that  an  erase,  the  frame,  and  any 
desired  frame  text  have  already  been  sent  by  the  segment.   The  line, 
text,  terminal,  and  then  instance  blocks  are  added  to  the  screen  via 
calls  to  R0UTX,  the  DPU,  and  GUT2  (RGINST).   Control  is  returned  to 
the  segment. 

GREGP1 

Entered  to  add  a  preformed  display  file  (such  as  a  text 
message  or  the  mnemonic  "box"  in  GNDRW)  to  display  file  being  constructed 
in  the  DPU  output  buffer.   The  call  is: 

TAD  X 
JMS  GREGP1 
FILEH 
FILEH ,    LEN 

(Rest  of  file) 

The  TAD  X  is  used  ONLY  if  the  file  ( FILEH)  is  not  in  GLBANK;  in  this  case, 

X  should  =  otherbank  -  GLBANK.   The  file  is  considered  as  an  entity  and 

is  added  directly  onto  the  current  file  with  DPUG.  When  the  DPU  buffer 
is  complete,  the  segment  should  call: 

TAD  X 

JMS  GREGP2 
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where  X  is  zero  or  any  desired  initial  700X  display  command.  A  DPUC  call 
will  be  set  up;  the  segment  should  follow  this  call  with: 

GIF  CDFIUTBANK 
JMS  I  XDPUDP 

to  send  the  display. 


SVPUT 


Pass  a  parameter  to  an  SVPRM  location  in  UTBANK: 


TAD  PARM 
JMS  SVPUT 
SVPRMn 


/n  =  1-8 


FREDPU 

Clear  the  DPU  flags    (DPUINP  and  DPUINF)   and  set   first  eight 
DPU  input  buffer  words  to  blanks    (i+O^O's).      This   allows  the  DPU  to 
asynchronously  store  more   input   into  the  buffer;   this   call  MUST  be  made 
as   soon   as  the  executing  segment  finishes  using  the  data  in  the  buffer. 
(JMS  FEEDPU). 


RETIME 


FREDTM 


Reset   the  timer  queue  element   for  ten  minutes.      (.JMS   RETIME). 


Calls   FREDPU,   then  RETIME.      (JMS  FREDTM). 


RLV1 

Use  the  data  stored  at  console  vector  location  +j6   to  form  a 
parameter  list  and  call  XCTL  (ACC  =  0).   Some  segments  store  return  data 
in  locations  +72  (level  3),  +lh   (level  2),  and  +l6   (level  l)  of  the  console 
vector  before  Invoking  a  segment  subfunction;  the  subsegment  uses  this  to 
return  via  RLV1,  RLV2 ,  or  RLV3  to  the  calling  segment.   (.JMP  RLVn). 
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M0VEDT 


Move  data  between  any  two  locations.      At  entry,   the  PDP-8 
data  field  register  specifies  the  hank  of  the-  calling  program.      Data 
is  moved  starting  at  the  specified  address   and  continuing  until  the 
word  count  reaches   zero.      The  call  is: 

CIFIGLBANK 

JMS  I   (M0VEDT 

From  addr 

To  addr 

From  bank  (00F0) 

To  bank  (00T0) 

Count  (>  0) 


SADCV 


ACC: 


Add  the  specified  word  in  the  current  console  vector  to  the 

JMS  SADCV 
disp  (0-77) 


SSTCV 


vector: 


Store  the  ACC  at  the  specified  word  in  the  current  console 

JMS  SSTCV 
disp  (0-77) 


SADPC 


Add  the  specified  word  in  the  current  PCB  to  the  ACC: 

JMS  SADPC 
disp  (0-177) 


SSTPC 


Store  the  ACC  at  the  specified  word  in  the  current  PCB: 

JMS   SSTPC 
disp  (0-177) 
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ST0P 

Reset  the  current  console  options  area  (+l^-...+37): 

TAD  X 
JMS  ST0P 
Addr 

Use  TAD  X  only  to  specify  that  less  than  2H„  words  are  to  be  reset 
starting  at  +lk   (e.g.,  2h   +  X  =  number  reset).  Addr  is  the  location 
of  the  new  contents  (in  GLBANK  only!). 

STWK 

Reset  the  current  console  -work  are  (+50... +77): 

TAD  X 
JMS   STWK 

The  use  of  TAD     X  is   analogous  to   its  use  in  ST0P.      The   data  moved  in 
is   assumed  to  be  located  at  +150... +177  in  GLBANK  page  0. 

LDWK 

Reset  +150. . .+177  in  GLBANK  page  0  from  the  current  console 
vector  work  area  (+50... +77): 

JMS   LDWK 

No  alternate  data  length  may  be  specified. 

SVPRLD 

Copy  the  current  console  vector  SVPRM  area  (+1+0... +^7)  to 
the  SVPRM  area  in  page  0  (+lU0. . .+1U7)  of  the  specified  bank: 

TAD  BNK 
JMS   SVPRLD 

BNK  =  OOnO,  where  n  =  3 (GLBANK)  or  l(UTBANK). 
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SVPRSV 

Copy  the  SVPEM  area  in  page  0  (+lU0., .+IU7)  of  the  specified 
bank  to  the  current  console  vector  SVPRM  area.  (+k0-. .  .+h"j): 

TAD  BIK' 
JMS  SVPBSV 

BNK  =  OOnO,  where  n  -  3(GLBANK)  or  l(UTBANK). 

T0LAC 

Test  current  console  status : 

TAD  X 

JMS  T0LAC 
+0  (inactive  return) 
+1  (offline  return) 
+2  (active  return) 

The  status  of  the  terminal  is  indicated  by  the  address  of  the  return.   If 
the  terminal  was  inactive  and  the  ACC  was  zero  on  entry  to  T0LAC,  T0LAC 
will  set  the  terminal  to  active  before  it  returns  at  +0.   If  the  ACC  was 
not  zero,  T0LAC  just  returns  at  +0. 

GLINE 

Calculate  a  line  number  (l...n)  for  a  given  Y  coordinate  given 
the  number  of  lines  in  the  list  and  the  Y  coordinate  of  the  top  line. 
The  input  Y  coordinate  is  assumed  to  be  in  +112  of  the  PCB  (e.g.,  set  by 
DPUDIN,  etc. ). 

JMS   GLINE   (ACC  MUST  =  0) 
List  length 
Top  Y  coord 

If  0  is  returned  in  the  ACC,  the  input  Y  missed  the  list.   This  routine 
is  obviously  handy  for  menu  picking. 
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APPENDIX  D 
GUTS  Service  Routines — Detail 
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1.   DSMN  Routines 


1.1  List 


Entries 


MNDPC  - 
MNNTRE  ■ 


Direct  call  entry 
R0UTX  call  entry 


R0UTX  Calls 

MEBTB  - 
MKTDEB  - 
MMIBA  - 
MGTILE  - 
MNINE  - 
MNL0DR  - 
MNMNEM  - 
MKMNIN   - 

MNNEN  - 
MNOTE  - 
MNREAL  - 
MNRED  - 
MNRPL  - 
MNST0R  - 


Block-to-block  data  transfer 

Delete  a  current  picture  block 

Initially  allocate  space  and  load  nev  block 

Insert  data  at  end  of  last  entry  in  current  block 

Insert  data  at  end  of  current  entry 

Load  a  current  picture  block  into  core 

Build  a  mnemonic  block  from  the  current  picture 

Integrate   a  mnemonic  as   an  instance  into  the 

current  picture 

Insert   a  nev  entry  in  the  current  block 

Insert  a  nev  entry  at  the  end  of  the  current  block 

Reallocate    (e.g.,   expand)   a  current  picture  block 

Reduce  the  allocation  of  a  current  picture  block 

Insert,   delete,   or  replace   data  in  the  current  block 

Explicitly  store   a  current  picture  block  in  an 

IR  temporary 


Direct  Calls 

MNBL0D  - 
MNBRS    - 

MWBSET  - 
MDffiSV   - 


Load  the  word  in  the  current  block  pointed  to  by  BLK0RG 

Reset   the   specified  block  from  its  PCB  entry  as   the 

current  block    (see  MNBSV) 

Store   the  ACC  in  the  word  pointed  to  by  BLK0RG 

Save   the   status   of  the  current  block  in  its 

PCB  entry   (see  MBRS) 
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MNDEN  - 
MNDTX  - 
MNEL0D  - 

MNELST   - 

MNENUM  - 
MNESET  - 
MNEXT  - 
MNEXTC  - 
MNFIX  - 
MNFPR  - 
MNFPRA  - 

MWFPRT  - 


MNHTTJ  - 

MNIBD  - 

MNINS  - 
MNLTH  - 

MNM0V  - 
MNMRK  - 

MNMVP  - 

MNNXTE  - 


Delete  the  current  entry  in  the  current  block 

Delete  text-lines  in  the  current  entry 

Load  the  word  in  the  current  "block  pointed  to 

by  ENT0RG 

Return  the  number  of  entries  in  the  current 

block  (calls  MMDRVE) 

Return  the  number  of  the  current  entry  (l...n) 

Store  the  ACC  in  the  word  pointed  to  by  ENT0RG 

Extract  the  specified  text-line  from  the  current  entry 

Extract  arbitrary  data  at  P0DTTR  in  the  current  entry 

Mark  the  specified  block  as  fixed 

Reset  the  P0INTR  in  the  current  entry 

Reset  the  P0INTR  to  the  beginning  of  the  data 

+MNM0D  in  the  current  entry 

Reset  ENT0RG  and  P0INTR  to  the  first  entry  in  the 

current  block  and  return  the  block's 

address  (BLK0RG) 

Return  the  highest  terminal  sequence  number  +1 

from  the  current  block  (assumed  to  be  a  terminal 

block)  or  return  0  if  no  terminals  in  the  block  yet 

Set  the  initial  data  for  a  block  and  mark  the 

block  initialized 

Search   for  a  Y,   X  match  on   an  instance 

Move  P0INTR  to  the  specified  K-th  text-line 

(or  the  end)   of  the  current  entry 

Move  the   specified  data  into  the  area  of  P0INTR 

Mark  the  specified  bits   in  the  specified  word 

of  the   current   entry 

Move   data   (<_  5  words)    from  SVPRMU-8  into  the 

area  of  P0INTR 

Move  ENT0RG  and  P0LNTR  to   the  next   sequential  entry 

in  the  current  block  and  return  an  error  if  block 

end  exceeded. 
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MNPERG  -  Position  ENT0RG  to  the  specified  n-th  entry  in 

the  current  block 
MNPL0D  -  Load  the  word   at  the  current  P0INTR  location 

MNPRG  -  If  the  current  "block  is  marked  in  core  and 

initialized,   its  core  is   released  by  a  call  to  MNFRE 
MNPSET   -  Store  the  ACC  at  the   current  P0INTR  location 

MNTR1  -         _         Search  current   (assumed  terminal)  block  for 

terminals  "with  the  specified  instance  sequence 

numbe r .      Call  MNS  CAN 
MNTR2   -  Same   as  MOTEL,  but   search  is  for  specified 

terminal  sequence  number 
MNTR3   -  Similar  to  MNTR1,  but   search  is   for  specified 

Y,   X  and  call  is  to  MNYXF 
MNTXS   -  Calls  MNYXF  to  search  the  current   (assumed  text) 

block  for  an  entry  that  matches  the  specified  Y,  X 
MNUNF  -  Mark  the  specified  block  as  unfixed 

MNYNM  -  Return  the  line  number  for  the  text-line  in  the 

current  entry  that   corresponds  to  the  input 

Y  value 
MN1EX  -  Extract  one  word  from  the   current  entry  at  the 

specified  location 
MN2TB  -  Move   data  from  the  system  2701  first-part  record 

input  buffer  to  the  current  block   (essentially 

MNIBD) ;   set  2701  input  I0T  data  for  the  second- 
part  of  the  record;   and  return  the  second-part 

input  address 

Internal  Routines    (some   of  these  are  NOT  restricted  to   DSMN  use) 


CTIME   - 


DECML  - 


DECTYP- 


Return   least  significant  two   decimal  digits  of 
an  input  binary  number  to  GLBANK  calling  routine 
Call  DECTYP  to   obtain  four  decimal  digits   of  an 
input  binary  number;   UTBANK  call  only. 
Convert  input  binary  number  to   decimal 
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DSMNG0  - 


D3MNG3  - 


DSMNGU  - 

DSMNG6  - 

DTYPE  - 

MNADST  - 
MNADTB  - 

MNALC 
MNB0ST  - 
MNBTAD  - 
MNCEW2  - 

MNDRVE  - 

MNFRE  - 

MMGET  - 


MNIDLM 
MNIDLR 
MNLDAD 


Calls  DSMNG6  to  access  IR  internally  for  writing, 
reading,  and  deleting  block  temporaries. 
Called  by  MNST0R,  MNDEB,  MNL0DR 
Called  from  DSMNG6  to  perform  actual  IR  call. 
Saves  and  restores  pertinent  terminal  data; 
calls  DSMNIR  in  GLASP  to  ensure  serialized  IR 
use  (via  GETDS  WAIT  priority  call). 
Same  as  DSMNG0  but  called  from  MNLDST  during 
MNL0DR  processing  (need  more  core). 
Common  routine  to  build  IR  parameter  list  for 
DSMNG3.   Called  from  DSMNG0  and  DSMNGU. 
Called  by  DECTYP  to  pack  four  decimal  digits 
into  two  words 
Extract  a  word  in  a  table 
Convert  a  block  address  to  a  block  (MNGET 
"page")  number 

NOT  a  routine,  but  the  MNGET  page  allocation  list 
Use  the  current  BLKNUM  to  extract  and  set  BLK0RG 
Convert  an  MNGET  page  number  to  a  block  address 
Set  location  Z  and  the  data  field  for  accessing 
word  two  of  a  PCB  entry- 
Move  ENT0RG  to  last  entry  in  current  block  and 
P0INTR  to  the  end  of  that  entry 
Set  the  indicated  group  of  pages  in  the  MNALC 
list  to  FREE 

For  the  specified  number  of  contiguous  pages 
desired,  return  the  block  number  of  the  first 
page  allocated.   All  blocks  in  the  group  are 
allocated  by  setting  the  appropriate  word  in  the 
MNALC  list  to  N0T  FREE.   If  not  enough  contiguous 
blocks  were  found,  -1  is  returned. 
Set  MNM0D  to  zero 
Set  MNRSL  to  -1 

Add  an  entry  to  the  end  of  MNLDDA  (see  below). 
If  a  similar  entry  appears  in  the  middle  of  MNLDDA. 
remove  it  before  adding  the  new  entry.   Called  by 
MNL0DR  after  a  block  is  successfully  loaded 
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MNLDDA  -      NOT  a  routine,  but  the  list  of  blocks  currently 
in  core,  whether  fixed  or  unfixed.  Each  one- 
word  entry  contains  the  addrsss  of  the  PCB 
control  entry  for  the  respective  block.   The 
last  word  on  the  list  represents  the  most 
recently  used  block  (see  MNLDST,  etc.) 

MNLDDL  -       Delete  an  entry  from  MNLDDA.   Called  from 

several  routines,  particularly  MNDEB  after  a 
block  is  no  longer  in  core 

MNLDFD  -       Called  from  MNLDAD  and  MNLDDL  to  find  a 
specified  entry  in  MNLDDA 

MNLDPR  -       Called  to  compress  MNLDDA  by  one  word  (delete 
an  entry)  from  MNLDDL  and  MNLDAD 

MNLDST  -      Write  out  in  an  IR  temporary  (as  well  as  free 

core  and  delete  from  MNLDDA)  the  oldest  unfixed 
block  in  MNLDDA.   Called  from  MNL0DR  when  out 
of  space 

MNMAT  -        Test  if  ACC  and  word  at  P0INTR  match.   Uses  the 

absolute  value  of  the  difference  and  masks  result 
with  MNRSL 

MNMVR  -        Move  data  into  DSBANK 

MNMVX  -        Move  data  within  DSBANK  in  reverse  (e.g.,  end 

to  beginning).   Used  to  expand  blocks  and  entries 

MNNIS  -        Called  by  MNRPL  to  complete  expansion  processing. 
Calls  MNREAL  to  expand  block,  then  moves  in 
remaining  data  from  MNRPL  operation 

MNNMST  -       Resets  BLKNUM  as  specified  by  ACC 

MNSALC  -       Set  the  specified  core  page  to  N0T  FREE  by 
marking  the  appropriate  MNALC  word 

MNSCAN  -       Scans  each  sequential  entry  in  the  current  block 
for  a  data  match 

MNSTNM  -       Same  as  MNNMST,  but  uses  SVPRM2  instead  of  ACC 
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MNTALC  -       Test  if  the  specified  core  page  is  marked 

FREE  or  N0T  FREE  in  MNALC 
MNTRMX  -       Position  ENT0RG  and  P0INTR  to  the  first 

terminal  entry  in  the  current  (assumed 

terminal)  block 
MNXTR  -        Extract  data  from  DSBABK. 
MNYXF  -        Calls  MNSCAN  to  perform  a  Y,  X  vicinity  test 

on  entries  in  the  current  "block 
MEYXMV  -       Sets  SVPRM5  and  SVPRM6  in  UTBAUK  from  +112  (Y), 

+113  (X)  in  the  current  PCB 
PCBXGA  -       Resets.  PCBADR  for  the  current  terminal.   Uses 

the  PCB  copy  of  BLKNUM  (e.g.,  current  block) 

to  reset  ENT0RG,  P0HTR,  and  BLK0RG 
PCBXGT  -       Calls  PCBXGA  after  fetching  current  console 

address  from  GLBA1K  (INTC0N).   Called  by 

MMTRE,  MDPC,  DPUPDC 
PCBXST  -       The  analog  of  PCBXGT.   Saves  current  BLKWUM  in 

PCB;  stores  EWT0RG  and  P0IWTR  as  appropriate 

(correct  BLK0RG  already  in  PCB  entry) 
SADPC  -       Add  word  at  specified  location  in  PCB  to  ACC 

(same  as  GLASP  SADPC ) 
SSTCV  -        Same  as  GLASP  SSTCV 
SSTPC  -        Same  as  GLASP  SSTPC 
UTNCV  -        Reset  console  vector  address  in  GLBANK  as 

specified  by  ACC 
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1.2  Discussion 

The  operation,  and  use  of,  many  DSMN  routines  is  obvious  and 
clearly  discernible  from  the  listings.   Only  the  more  complex  and  critical 
routines  will  be  described  here. 

Loading  a  data  structure  block  in  the  current  picture  is 
normally  straightforward.   If  the  block  is  already  in  core,  the  PCB 
entry  is  marked  by  MNL0DR  as  fixed  and  ENT0RG,  P0INTR,  BLKNUM,  and 
BLK0RG  are  reset  to  indicate  that  the  specified  block  is  now  the  current 
block.   If  the  block  is  not  already  in  core,  it  must  be  either  in  an 
IR  temporary  or  not-initialized.  MNL0DR  uses  the  allocated  page  length 
in  word  one  of  the  PCB  entry  to  request  space  from  MNGET.   If  MNGET 
returns  the  first  page  number  of  a  suitable  contiguous  area,  MNL0DR  can 
complete  its  processing.   The  block  is  brought  in  from  IR  (via  DSMNG0) 
unless  the  PCB  entry  is  marked  not-initialized;  noninitialized  blocks  are 
never  stored  in  IR  temporaries.   ENT0RG,  P0INTR,  BLKNUM,  and  BLK0RG 
are  set  as  above,  and  the  proper  return  code  is  saved  (0K  or  not- 
initialized).   Finally,  MNL0DR  places  the  PCB  entry  address  for  the 
specified  block  on  the  end  of  a  special  list,  MNLDDA.   This  list  contains 
a  one  word  entry  for  each  block  that  is  successfully  loaded  by  MNL0DR, 
with  the  last  entry  being  the  one  most  recently  loaded.  Whenever  a 
loaded  block  is  stored  in  an  IR  temporary  or  deleted  (MNDEB)  from  the 
current  picture,  its  entry  in  MNLDDA  is  deleted.   The  page  list  in  MNGET 
(e.g.,  MNALC)  plus  the  cronological  in-core  block  list  (MNLDDA)  provides 
a  description  of  core  availability  and  usage  in  DSBANK  at  any  time. 

Note  that  in  addition  to  the  obvious  R0UTX  call,  MNL0DR  may 
be  invoked  by  other  circuitous  paths.   A  simple  one  is  via  MNIBA;  the 
equivalent  of  MNDEB  is  performed,  then  MNL0DR  is  called  to  set  up  the 
space  in  core  (e.g.,  not-initialized  is  the  usual  return  code  of  MNIBA). 
A  deeply  embedded  path  is  via  MNRPL:   a  block  must  be  expanded  to  accept 
inserted  data,  so  MNNIS  and  MNREAL  are  called.   MNREAL  explictly  stores 
the  block  (MNST0R)  in  an  IR  temporary  and  alters  the  page  allocation  in 
the  PCB  entry.   Then  MNREAL  calls  MNL0DR  to  bring  the  block  back  into 
core  with  the  new  space  allocation. 
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The  problem  arises,  of  course,  when  MNGET  does  not  locate 
enough  space.   MNLDDA  now  comes  into  use;  MNL0DR  calls  MNLDST  to 
swap-out  an  ,in-core  block.  MNLDST  scans  the  list  of  blocks  to  find  the 
least  recently  used  block  that  is  unfixed.   Fixed  blocks,  by  definition, 
cannot  be  swapped-out.   If  no  unfixed  blocks  are  found,  a  lockout 
condition  has  occurred;  MNL0DR  must  pass  the  appropriate  return  code.   If 
an  unfixed  block  is  found,  its  entry  is  removed  from  the  list,  and  the 
block  is  written  into  an  IR  temporary  via  DSMNGU.   The  core  occupied  by 
the  block  is  then  released  via  MNFRE,  and  MNLDST  returns  to  MNL0DR. 
MNL0DR  again  tries  to  load  the  desired  block  (e.g.,  calls  MNGET  for 
space)  and,  if  successful,  processing  terminates  as  above.   If  the  block 
still  cannot  be  allocated,  MKTLDST  is  called  again.   This  continues  until 
either  the  block  is  loaded  or  MNLDST  runs  out  of  unfixed  blocks. 

MNRPL  is  a  very  general  routine  for  altering  data  within  the 
current  data  structure  block,  as  is  shown  by  the  parameter  descriptions 
in  the  listing.  MNRPL  first  calculates  the  length  of  data  to  be  removed 
and  stores  this  value  in  MNRPL^;  a  simple  test  ensures  that  the  length 
does  not  exceed  the  size  of  the  current  entry.   The  displacement  from 
ENT0RG  to  P0INTR  is  saved  in  MNRPL5;  this  value  is  used  to  reset  P0INTR 
after  the  operation.   The  difference  between  the  lengths  of  the  data  to 
be  removed  and  the  data  to  be  inserted  is  saved  in  MNRPL6;  this  is  the 
amount  that  the  entry  (and  block)  must  be  contracted  or  expanded.   MNM0V 
is  then  called  to  move  in  all  of  the  input  data  (MNRPL6  is  positive, 
removal  len  >  insert  len)  or  the  first  part  of  the  insert  data  (MNRPL6  is 
negative,  removal  len  <  insert  len;  MNRPLU,  the  removal  length,  is  used 
instead  of  S VPRM7  ,  the  insert  length,  for  the  call  to  MNM0V) .   If 
MNRPL6  is  in  fact  zero,  the  replacement  was  exact,  so  a  CLuick  exit  is 
taken.   Otherwise,  P0INTR  and  SVPRM6  are  incremented  by  SVPRM7  (e.g.,  the 
T0  and  FR0M  addresses,  respectively,  now  reflect  the  MNM0V  operation), 
and  MNRPL6  is  checked  again.   For  MNRPL6  positive,  the  block  only  needs 
to  be  contracted.   After  some  setup,  the  block  length  and  entry  length 
are  altered,  and  MNMVR  is  called  to  move  up  the  rest  of  the  block  to  the 
current  P0INTR.   Finally,  P0INTR  is  reset  using  MNRPL5  to  its  original 
position  relative  to  ENT0RG,  and  MNRPL  exits.   For  MNRPL6  negative,  the 
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"block  must  be  expanded  and  the  remaining  insert  data  moved  in.  MNNIS 
is  called  for  this;  after  expanding  the  "block  allocation  with  a  call  to 
MNREAL,  MNMVX  is  used  to  move  the  end  of  the  block  down  to  accommodate 
the  rest  of  the  insert  data.   The  block  length  and  entry  length  are 
increased  appropriately,  MNM0V  is  called  to  bring  in  the  data,  and  MNNIS 
returns  to  MNRPL.   MNRPL  resets  P0INTR  and  exits. 

The  only  hooker  in  the  above  procedure  is  the  call  to  MNREAL. 
As  will  become  apparent  in  the  following  description,  processing  in 
MNREAL  may  be  extremely  lengthly  and  might  involve  a  great  amount  of  disk 
accessing.   Keep  in  mind  that  MNRPL,  even  more  so  than  MNL0DR,  may  be 
entered  via  a  large  variety  of  paths.   MNINE,  MNNNE,  MNILE,  and  MNNEN,  amon^ 
others,  all  call  MNRPL.   One  of  the  potentially  worst  cases  occurs  when 
MNRPL  is  called  by  MNBTB ;  both  blocks  must  be  in-core  and  fixed  during  the 
entire  procedure.   In  fact,  as  the  two  blocks  in  question  approach 
maximum  size  (l/2  bank  each),  the  likelihood  of  a  lockout  increases 
rapidly,  since  even  a  small  fixed  block  from  any  other  terminal  could 
fragment  core . 

To  expand  the  allocation  of  a  block,  MNREAL  first  tries  to  add 
free  core  pages  to  the  end  of  the  block.   MNREAL  calculates  the  page 
number  of  the  core  page  just  after  the  block;  MNTALC  is  called,  and  if 
the  page  is  FREE,  MNREAL  calls  MNSALC  to  set  the  page  N0T  FREE.   The 
block  allocation  in  the  PCB  entry  is  incremented  by  one,  and  the  number 
of  extra  pages  needed  is  decremented  by  one.   If  more  pages  are  still 
needed,  the  above  process  is  repeated.   If  enough  pages  can  be  added  in 
this  way,  MNREAL  will  take  a  quick  return  to  MNNIS.   However,  if  MNTALC 
finds  that  the  requested  page  is  already  marked  N0T  FREE,  the  block  cannot 
be  sufficiently  expanded  in  this  simple  way.   So  MNREAL  saves  the 
displacements  of  P0INTR,  ENT0RG,  SHDPTR,  and  SHDERG  from  BLK0RG.  When 
the  block  is  relocated  in  core,  these  displacements  are  used  to  reset 
the  pointers  to  their  original  positions  within  the  block. 

To  relocate  the  block,  MNREAL  first  calls  MNST0R  to  write  the 
block  into  an  IR  temporary.   The  first  word  of  the  PCB  entry  is  then 
altered  to  contain  the  entire  block  allocation  needed  plus  bits  indicating 
not-in-core  and  initialized.   MNL0DR  is  then  called  to  bring  the  block  in 
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with  the  new  space  allocation.  Note  that  the  MNST0E  freed  the  space 
currently  used  by  the  block  as  well  as  caused  its  entry  in  MNLDDA  to 
be  removed.-  If  MNL0DR  is  lucky,  MNGET  will  find  enough  contiguous  core 
in  some  other  part  of  DSBANK  for  the  new  block.   Otherwise,  MNLDST 
will  be  called  to  start  swapping -out  unfixed  blocks.   Obviously, 
overhead  for  this  particular  MNKPL  operation  has  become  quite  high  at 
this  point ! 

When  MNL0DR  successfully  loads  the  block,  MNREAL  resets  the 
pointers  using  the  stored  displacements  and  calls  PCBXT  to  copy  these 
new  values  into  the  PCB  entry.  A  return  is  then  made  to  MNNIS.   If 
MNL0DR  was  NOT  successful,  this  unfortunate  event  must  be  filtered  all 
the  way  back  to  the  routine(s)  that  initiated  the  operation. 

For  working  internally  with  IR  temporary  files,  DSMNG0  and 
DSMNGU  call  DSMNG6  to  set  up  an  IR  parameter  list;  DSMNG3  is  then 
called  to  perform  the  actual  IR  linkage.  Note  that  if  DSMNGij-  -was  called 
by  MNLDST  after  a  call  to  MNL0DR  from  MNREAL  during  MNRPL  processing  of 
a  MNBTB  operation. . .things  are  really  tied  up!   And  they  will  get  worse! 
Not  only  is  core  held  by  fixed  blocks  and  DSMN  as  a  service  is  busy,  but 
IR  as  a  service  will  also  be  tied  up  during  DSMNG3  processing. 
Fortunately,  the  CPU  and  disk  are  quicker  than  the  terminal  users  (usually). 

DSMNG3  saves  the  terminal's  status  within  its  own  save  areas 
during  IR  processing;  since  DSMN  as  a  service  is  busy,  DSMNG3  cannot  be 
re-entered,  so  this  saved  information  will  not  be  wiped  out.   Unfortunately, 
DSMNG3  cannot  possibly  save  all  of  the  intermediate  routine  returns  and 
temporary  locations;  hence,  there  is  no  alternative  to  DSMN  remaining 
busy  as  a  service.   The  areas  saved  are: 

1.  Current  block  pointers  (via  PCBXST) 

2.  UTBANK  SVPRM1-8 

3.  Console  vector  SVPRM1t8 

h.      Console  vector  R0UTX  return  data 

A  call  to   DSMNIR  in  GLASP  is  then  made;   DSMNIR  issues   a  priority  WAIT 
request    (GETIR)   and  returns  when  IR  is   free.      DSMNG3  moves  the  IR 
parameter  list   formed  by  DSMNG6   into  SVPRM1-8  in  GLBANK  and  calls  IR 
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via  R0UTX.  Areas  3  and  h  saved  above  would  obviously  be  wiped  out  by  the 
R0UTX  call  to  IR;  while  IR  is  in  operation,  DPU  servicing  or  other  direct 
routine  calls  could  easily  wipe  out  the  information  in  areas  1  and  2. 

When  IR  processing  is  complete,  0PD0NE  will  return  to  DSMNG3; 
the  R0UTX  call  is,  for  all  external  appearances,  quite  normal.   DSMNG3 
resets  the  current  console  (INTC0N)  in  GLBANK  and  restores  all  four 
areas  previously  saved.   The  complete  status  of  the  terminal  and  DSMN  is 
now  the  same  as  before  the  IR  call.   DSMNG3  returns  and  DSMN  processing 
continues . 

Creating  the  initial  form  of  a  mnemonic  storage  block  (MSB) 
from  the  current  picture  is  the  tedious  task  performed  by  MWMNEM.   The 
only  input  to  this  routine  is  the  Y,  X  values  needed  to  position  the 
parameter  model  list,  plus,  of  course,  the  current  picture.   MEMNEM  first 
allocates  (via  MNIBA)  a  two  page  work  area  in  block  12  q  and  initializes 
this  new  block  via  MNIBD  as  follows: 
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Total  block  length 

First  entry  length  (control  entry) 

Space  for  six  character  name 


Default  type  word  (name.O) 

Space  for  Y  and  X  when  used  as 

an  instance 

Space  for  instance  sequence  number 

when  used 

Space   for  creator's   ID 

Second  entry  length   (param  model  entry) 

Position  of  the  parameter  model   list 

as  specified  by  input 

Third  entry  length   (type-name  entry) 

Y,   X  of  top  menu  line 

Fourth  entry  length  (terminal  list  entry) 
Fifth  entry  length   (line  entry) 
Line  entry  displacements 
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The  above  is  functionally  complete.   If  the  current  picture  has  an  empty 
type-name  list ,  no  external  terminals ,  an  empty  line  clock  and  an 
empty  text  .block,  saving  the  above  data — even  if  the  calling  program  does 
not  insert  the  six  character  name,  the  ID,  or  call  the  text  editor  to  fill 
in  the  parameter  model  entry — will  result  in  a  usuable  (though  very 
uninteresting)  mnemonic.   Note  that  when  an  MSB  is  used  to  create  an 
instance  in  a  picture  (e.g.  "integrated"  by  MNMHIN),  the  first  three  MSB 
entries  are  copied  bodily  into  the  picture's  instance  block;  the  terminals 
in  entry  four  are  inserted  into  the  picture's  terminal  block.   In  both 
these  cases,  MNMNIN  modifies  certain  Y,  X  values  in  the  copied  data; 
these  modifications  are  described  in  the  discussion  of  MNMNIN  below. 
Whenever  a  picture's  instance  block  is  displayed,  the  line  and  text 
portions  of  each  referenced  constituent  instance  are  recreated  from  the 
respective  MSB.   In  this  case,  certain  displacements  are  added  to  the 
Y,  X  values  in  the  line  (entry  5)  and  text  (any  subsequent)  entries  as 
display  file  formatting  is  performed.   This  is  also  discussed  in 
MNMNIW  below. 

Consult  Figure  11;  after  forming  the  above  "empty"  mnemonic, 
MNMNEM  proceeds  to  fill  in  data  whenever  available  from  the  current 
picture.   If  certain  data  is  not  available,  the  corresponding  entry  in 
the  MSB  remains  empty  but  functionally  complete.   Entry  one  is  already 
complete;  the  calling  program  is  responsible  for  filling  in  the  name,  the 
type  word,  and  the  creator's  ID  before  calling  SVENMN  to  add  the  MSB  to 
the  library.   The  Y,  X  and  instance  sequence  number  locations  are  not 
used  until  MNMNIU  integrates  the  MSB  as  an  instance.   Entry  two  is  also 
already  complete;  the  calling  program  is  responsible  for  calling  the  text 
editor  so  that  the  terminal  user  may  enter  the  desired  parameters.   If  no 
such  call  is  made ,  entry  two  is  just  a  text  entry  with  no  lines .   Setting 
the  third  entry  is  a  good  demonstration  of  the  block-to-block  facility; 
MNMNEM  proceeds  as  follows. 

The  MSB  (block  12)  is  the  current  block;  it  is  in-core  and 
fixed.   MNPEEG  is  called  to  position  ENT0RG  and  P0INTR  to  the  third  entry; 
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MNBSV  is  then  called  to  save  the  current  status  (e.g.  ENT0RG  and  P0INTR) 
of  the  current  "block  (No.  12)  in  the  appropriate  PCB  entry  (PCB+60). 
MNL0DR  is  called  to  load  the  terminal  block  (block  k) ;  this  makes  block  h 
the  current  block.   If  lockout  occurred  during  MNL0DR,  a  quick  exit  is 
taken  and  the  calling  routines  must  check  for  this  return  code;  the 
terminal  user  should  simply  try  the  operation  again.   If  "block  k   is  not 
initialized,  there  can  be  no  type  name  list,  so  entry  three  of  the  MSB 
will  remain  as  it  is.   Block  k   is  set  unfixed,  block  12  is  left  in  its 
"saved"  condition,  and  MNMNEM  proceeds  to  load  the  line  block  (No.  0); 
see  below.   If  block  k   is_  loaded  successfully  (e.g.,  it  is  initialized), 
MNBSV  is  called  to  save  its  status,  as  was  done  for  block  12.   Note  that 
MNL0DR  always  sets  ENT0RG  and  P0INTR  to  the  first  entry  in  the  loaded 
block;  since  the  first  entry  in  the  terminal  block  contains  the  type  name 
list ,  this  is  the  entry  that  will  be  used  to  set  the  third  entry  in  the 
MSB.   Hence,  MNPERG  was  NOT  called  before  MNBSV,  since  the  desired 
entry  was  already  pointed  to.   MNBRS  is  now  called  to  make  the  MSB, 
block  12,  the  current  block  again;  the  appropriate  pointers  are  reset  from 
ENT0RG  and  P0INTR  in  the  PCB+60  entry.   The  MSB  with  its  pointers  set  to 
the  third  entry,  is  the  T0  block,  while  block  k   with  its  "saved"  pointers 
set  to  the  first  entry  is  the  FR0M  block.   MNBTB  is  now  called  to  "replace" 
the  data  in  the  current  T0  block  location  with  a  copy  of  the  data  at  the 
FR0M  block  location.   Obviously,  since  the  MSB  may  be  expanded  by 
subsequent  calls  to  MNREAL  from  MNRPL,  the  lockout  condition  must  be 
tested  when  MNBTB  returns  to  MNMNEM.   If  lockout  occurred,  a  quick  exit  is 
taken,  as  above.   If  the  operation  completed  normally  ,  MNMNEM  proceeds  to 
work  on  MSB  entry  kt   the  terminals.   Note  that  even  in  the  case  of 
normal  completion,  the  MSB  might  now  be  in  a  different  core  location;  the 
pointers,  ENT0RG  and  P0INTR,  were  properly  reset  to  the  necessary 
relative  locations  within  the  block  by  MNREAL. 

Processing  the  other  entries  in  the  MSB  is  handled  in  the  same 
fashion.   The  pointers  to  the  desired  MSB  entry  are  set,  and  the  MSB  is 
"saved"  with  MNBSV.   Then  the  desired  picture  block  is  loaded,  its 
pointers  set,  and  its  status  saved  with  MNBSV.   The  MSB  is  made  the  current 
block  with  MNBRS,  and  MNBTB  is  called  to  transfer  the  data.   At  all 
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appropriate  points,  lockout  is  tested.   Uninitialized  "blocks  are  checked 
for,  and  all  "blocks  are  unfixed  as  soon  as  possible. 

After  successfully  setting  the  type  name  entry  in  the  MSB, 
MNMNEM  calls  MNNXTE  to  set  the  pointers  to  the  fourth  (terminal's) 
entry;  the  MSB  status  is  then  saved  with  MNBSV.   Since  the  terminal 
block,  No.  4,  is  already  loaded,  MNBRS  is  called  to  make  it  the  current 
block.   Its  pointers  are  then  moved  to  the  first  terminal  entry,  and 
MNMNEM  proceeds  to  extract  each  external  terminal  and  insert  the 
appropriate  terminal  data,  if  any,  into  the  MSB.   Finally,  all  terminals 
are  checked,  MSB  entry  four  is  complete,  and  the  terminal  block  is 
unfixed.   MNMNEM  is  now  ready  to  process  the  picture's  line  and  text  blocks. 

The  first  (only)  entry  in  the  line  block  (No.  0)  is  copied  into 
the  MSB's  fifth  entry  in  a  manner  directly  similar  to  the  processing  of  the 
type  name  entry  described  previously.   Then  each  entry,  if  any,  in  the 
text  block  (No.  l)  is  added  as  a  new  entry  at  the  end  of  the  MSB.   In  this 
case,  MNBTB  is  called  so  that  MNNNE  is  used  instead  of  MNKPL. 

The  MSB  is  complete  ;  MNMNEM  processing  terminates . 

As  mentioned  in  MNMNEM,  the  MSB  is  used  (l)  to  form  an  instance 
in  the  current  picture's  instance  and  terminal  blocks,  and  (.2)  for 
displaying  the  line  and  text  portions  of  the  instance  during  REGEN. 
When  MNMNIN  is  entered,  it  assumes  that  the  MSB  to  be  integrated  into  the 
current  picture  is  already  loaded  in  block  12ft;  processing  is  essentially 
carried  out  as  in  MNMNEM.   That  is,  MNBSV,  MNBRS ,  and  MNBTB  are  used  to 
copy  information  from  the  MSB  to  the  instance  and  terminal  blocks;  the 
same  type  of  error  checking  (lockout,  not-initialized,  etc.)  is  also  used. 
The  only  input  to  MNMNIN  is  the  Y,  X  position  of  the  instance  center.   Note 
that  when  the  MSB  was  constructed,  the  locations  of  the  terminals,  the 
parameter  model  list,  the  lines,  and  the  text  entries  were  all  stored 
as  absolute  screen  coordinates.   However,  when  displayed  as  an  instance, 
this  information  must  be  displayed  relative  to  the  instance  center.   To 
facilitate  this  adjustment,  the  MSB  is  assumed  to  have  been  created  with 
its  center  at  (1000,  1000).   The  adjustment,  then,  consists  of  setting 
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YD  =  Y  +  (YN-1000) 
XD  =  X  +  (XN-1000) 

where  YD  and  XD  are  the  adjusted  coordinates  for  the  instance,  Y  and  X 
are  the  coordinates  stored  in  the  MSB,  and  YN  and  XN  are  the  input 
coordinates  of  the  instance  center.   Consult  Figures  9  and  12. 

MNMNIN  builds  the  control  entry  (first  of  three  entries  to 
be  added  to  the  instance  block)  from  the  data  in  the  first  MSB  entry, 
the  input  Y,  X,  and  the  instance  sequence  number  (INST).   INST  is 
obtained  by  adding  one  to  the  INST  found  in  the  last  instance  (call  to 
MNDRVE  followed  by  call  to  MNPERG  plus  a  call  to  MNPL0D).   If  the 
instance  block  has  not  previously  been  initialized,  it  is  initialized, 
and  zero  is  used  for  INST.   The  control  entry  is  added  to  the  instance 
block  with  MNNNE. 

The  parameter  model  entry  is  added  to  the  instance  block  next ; 
then  the  entry's  Y,  X  is  adjusted  to  YD,  XD.   The  type  name  entry  is  the 
last  of  the  three  entries  to  be  added  to  the  instance  block;  its  Y,  X  is 
not  altered  since  it  is  always  displayed  in  the  menu  area  if  used.   The 
instance  block  is  now  set  to  unfixed,  and  the  terminal  block  is  loaded. 

If  the  terminal  block  was  not  initialized,  it  is  initialized 
now;  zero  is  used  for  the  first  terminal  sequence  number  (TRM).   Each 
terminal  in  the  MSB's  fourth  entry  is  extracted;  the  Y,  X  is  altered  to 
YD,  XD;  the  next  TRM  is  obtained  with  a  call  to  MNHTN;  and  the  resulting 
entry  is  added  to  the  terminal  block.   This  continues  until  all  terminals 
are  extracted.   Then  the  terminal  block  is  marked  unfixed;  block  12  is 
left  as  the  current  block;  and  MNMNIN  processing  is  at  an  end. 

During  display  of  the  line  and  text  entries  of  an  MSB,  DPUM 
uses  the  YN,  XN  obtained  from  the  instance  control  entry  for  the  instance 
to  modify  the  appropriate  Y,  X  fields.   Consult  DPUM  in  the  listing. 
The  terminals  and  parameter  model  list,  of  course,  are  already  set  to  the 
proper  locations  due  to  MNMNIN 's  manner  of  integration. 
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2.   DPU  Routines 


Entries 


DPUENQ 
DPUPDC 


R0UTX  call  entry 
Direct   call  entry 


R0UTX  Calls 
DPUENQ 


Immediate  operations ;  enqueue  DPU 


Direct  Calls  ("Add  data  to  the  current  display  file"  =  AD) 


DPUA  - 
DPUB  - 
DPUC  - 

DPUDI  - 

DPUDP  - 
DPUDV  - 
DPUE  - 

DPUF  - 
DPUG  - 
DPUH  - 
DPUI   - 

DPUJ   - 

DPUK  - 

DPUL   - 

DPULY  - 
DPUM  - 

DPUNL  - 


Display  a  text -line 
Display  a  line 

Display  an  arbitrary  preformed  file   or  display 
the   current  display  file   just  built 
AD  to  move  the  "beam  invisibly   (blanked) 
with  a  vector 

AD  to  move  the  beam  visibly  or  invisibly  ■with  a  point 
AD  to  move  the  beam  visibly  with  a  vector 
AD  to  display  the  specified  text-line  at   a 
specified  Y,   X 

AD  from  <_  five  words  from  SVPRMU-8 
AD  of  any  arbitrary  length 
AD  consisting  of  a  specified  vector  block 
AD  formatted  from  the  text-lines  of  the 
current    (assumed  text)   entry 

AD  formatted  from  the  text-lines   of  all  entries 
in  the  current    (assumed  text)  block 
Uses   DPUKA  and  DPUKB  to  send  the  specified  text- 
line  to  the   terminal's   character  line  buffer 
AD  formatted  from  the  terminals  and  terminal 
connections  of  the   current   (assumed  terminal)  block 
AD  formatted  from  the  specified  terminal  entry 
AD  formatted  from  the   current   (assumed  mnemonic 
storage)  block 

AD  formatted  from  the  point  groups  of  the  current 
(assumed  line)  block 
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Internal  Routines 


DPUDQ  - 


DPUFER  - 
DPUHBN  - 
DPUHL   - 

DPULEN   - 

DPULW  - 

DPULX  - 

DPUMl+X  - 

DPU0NE  - 
DPUPNT   - 

DPUQ  - 

DPURAD  - 

DPUREF  - 


After  display  file  complete  (and  being 

transferred  by  DPU) ,  link  to  DPUDQ1  in 

GLASP  to  await  DPU  completion.   DPUDQ1  sets 

WAIT  priority  call  GTDPU;  then  returns 

control  to  segment  via  XCTL2  (immediate 

command)  or  XCTLS  (direct  call)  as  appropriate 

Save  specified  reference  center  input 

Turn  high  (bit  0)  ACC  bit  on  (=l) 

Add  an  exit  mode  sequence  (0000,  U000)  to 

the  display  file 

Check  that  enough  space  is  left  in  the 

display  file  buffer  for  the  next  insert 

Display  terminal  connections ;  all  or  just 

visible  connections  can  be  specified 

Display  terminal  symbols  and/or  characters 

as  specified 

Called  from  DPUM  to  display  the  line  entry  of 

a  mnemonic  storage  block 

Add  the  single  word  in  the  ACC  to  the  display  file 

Increment  P0INTR  by  1  and  load  the  ACC  from  the 

word  at  that  location 

Increment  or  decrement  the  display  file  pointer 

by  the  ACC  amount 

Reset  the  display  file  pointer  to  the  beginning 

of  the  buffer  and  set  an  initial  command  (if 

SVPRM8  not  zero) 

Reset  the  reference  center  with  the  saved  data 

(see  DPUFER) 


All  DPU  routines  perform  well-defined  functions   in   a  straight- 
forware  manner.      The  necessary  parameter   list  and  a  short  description 
precede  each  routine  in  the  listings. 
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APPENDIX  E 

CALR  (CALRl) :0 

P- 

120 

GSAM  ( GSAMV1 ) : 1 

P- 

123 

GUT1  (TEXTHN) : 30 

I>- 

125 

GUT2 : 31 

P- 

129 

GUT3  (REACT): 32 

P. 

133 

DEX1  (DEXCHK)  :33 

P- 

138 

PSIR  (IRINIT) :3T 

P. 

139 

CALR    (CALRl)  ;0 
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CALRl    (*U000) 
System  Entry 


CLEAR   CONSOLE 
VECTOR  AND  PCB 
TO   ZERO. SET 
DEVICE  ENTRIES. 
SET  FIRST  DISPLAY 


SEND  DISPLAY^O 
Iterminal  (CAL0UT) 


RELE3E 
(Await   Input) 


DPU       TIMER   (Program  Pick) 
aboard     (Loggon) 
( Logon ) 


B    )   CALTM1 


/SAVE  MENU  B 
\INIR   (SVNMB, 


CALTM3  V 


ERASE  SCREEN  DPU) 
DELETE  CORE  COPY 
OF  MENU  BLK  (fNDEB) 
SET  TERMINAL 
INACTIVE 


PRINT  LOGO 
TTY  MSG  (L0G) 


I 


RELESE 
(Exit  from  CALR) 


CALR2    (*l+200) 

Called  Program  Return 


CLEAR   CONSOLE 
VECTOR  AND  SAFETY 
DELETE    (MNDEB) 
OF  ALL  BLOCKS. 
CLEAR  PCB 


A     ) CALDP1 


SAVE  FIRST 
SIX  KEYBOARD 
WORDS  (FREDPUJ 


3all  dex1  to 
:heck  logon  spring 


CALSRX 


CALSRX 

/print  THREAT 
\^TY  MSG   (L0G1 


CALN0N 


SET  NOT 
FOUND  MESSAGE 
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0 

i 

Sprint  logon\ 

(tTY  MSG    (L0GW 


CALGKX' 


READ  MENU 
BLOCK   (LDNMBkI) 


CORRECT  THE 

ALLOCATION  IP 

EXISTED  (MNRED) 

OR  INITIALIZE 

A  NEW  BLOCK  IF 
PIP  NOT  EXTST 


CALDP3 


RESET  DEVICE 
INPUTS  AND 
TIMER. SET 
PROGRAM  PICK 
DISPLAY 


(Program  Pick) 

2701  (MSG) 
C2  )  Timer  (CALTM2) 


Keyboard  ( CALTM U) 

ch    )   Menu  (CALMEN) 
Logout  (CALTM) 

CALTM2 


SET  TIME   DEVIDE 

ADDRESS   FOR 

LOGOUT  (CALTmL) 
SET  AUTO- 
LOGOUT  MSG 


MSG 


'SEND  2701 
TEXT   LINE 
TO   TERMINAL 
(GLMSGA) 


RELESE 


© 


CALTM 


FREDPU 


'PURGE  ALL 
^ILES   LISTED 
CN  MENU  BLOCK 
FROM  LOCAL  I J 
JjLEJPJ 


FREDTM.,  SET 
"what?"  MSG 
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CALMEN 


ALLOCATE   STND 
BLOCKS . CLEAR 
DEVICE  ENTRIE$ 
SET  LEVEL  1 
RETURN   FOR 
CALR2 


I 


XCTL  TO  PROGRJM 

AS  PER  TABLE    (AVAIL) 
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GSAM   (GSAMVl):! 

GSAMVl   (*U000) 
Level  X  Entry 


ET  CONSOLE 
VECTOR   (ST0P) 
FOR  MAIN  MODE 
ENQUE   DPU.ADD 
MIS  MODE  TEXT! 
EN  MENU  AND 

KOMPT   ATffiAS 


GSAM3 


ADD  FRAME, 
SYSTEM  LINE, 
USER  LINE, 
RETURN,  PANIC 


GSAM2 


SEND  TO 
TERMINAL 
(GREGP2,    DPUPtC) 


t 

RELESE 

(Await   Input) 


Timer     DPU         DFU 
(main      (sub 
mode )     mode ) 


A     )  G2TIN 


/DISPLAY  LINEN 


RELESE 
(Await   Input) 


0 


B    I   GTMRIN 


RESET  TIMER  TV 
2  MEN. RESET 
TIMER  INPUT 

ADDR  TO 
BEJnifflIg2j 


ENQUE  DPU,   ADD 
"AUTO   RETURN"!  MSG 


( mainmode ) 

Menu  (GJSMNH) 

C2  )    Return   (GJSREH) 


(submode) 

Menu  (GSPECY) 

D2   )     Return   (GSPECX) 


^■RELESE 
(Await    Input) 


GC0NS,    GC0MU 


SET  LEVEL  2 

RETURN  TO 

GSAMV1.  XCTL 

TO  GNDR  OR  TO 
REACT 


GSPEC  \ 

1 

RESET  DPU 
RETURN  AND 
MENU  INPUT 
FOR  SUBMODE 

1 

' 

ENQUE   DPU. 
ADD  ERASE, 
"SPECIFY"          ! 
MENU,   PROMPT 
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Dl    )    GSPECY 


»RELESE 
(Await   Input 


SET  BLOCK  NO, 
AND  ENTRY  NO, 
FOR  TEXT 
ENTRY  EDITOR 


LOAD  REQUESTED 
BLOCK    (5   OR  6) 
INITIALIZE   IF 
NOT-INITIALIZED 


GSPEC  A  il 


SET  APPROP- 
RIATE MSG  INTO; 
PCW0RK  FOR 
TEXT  EDITOR 


SET  LEVEL  3 
RETURN   TO 
GSPEC5    (D3) 
XCTL   TO   GUT1 


C2 


GJSREH 


D2        GSPECX 


FREDTM 

RLV1  TO    CALR 


FREDTM 


(Exit    GSM) 


GSAMV1 


D3 


GSPEC5 


RESET   CONSOLE 
VECTOR   (ST0P) 
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GUT1    (TEXTHN):30 

TEXTHN    (*l+000) 
Level   3  Entry 


Dl   APPEND 


CLEAR 
GREGEN  FLAG 


REGENT 


PASS  APPEND  MOID 
KEYBOARD  ADDR 


LOAD  INDICATEI 
BLOCK  TO  BE 
MODIFIED.  ENQUI 
DPU.ADD  ALL 
FRAME   TEXT. 
ADD  INDICATED 
ENTRY   FROM  BLE 


SET  KEYBOARD 
INPUT  ADDRESS 
CLEAR  HITS 
FLAG 


UNFIX  BLOCK, 

ADD  MSG  FROM 

PCW0RK.SEND 
DISPLAY   TO 
TERMINAL 


RELESE 
(Await   Input) 


DO   REGEN 


A   J    I    B     J     f    C 

Timer     2701       DPU 

A    J P0PT 


(Exit   GUT1) 


RESET  CONSOLE 
VECTOR   (ST0P) 


£ 


C0MIN 


DISPLAY  LIN$, 
[  CLEAR  2701 
I  VTA  GLMSGA 


7 


RELESE 
( Await   Input ) 
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Answer   (REGEN) 

C2   )   Eeturn    (P0PX) 
C3    )   Draw   (PICK) 

Light  Button   (FUNKY) 
C5    )  Keyboard  Append  (APPL) 

Keyboard  Insert    (INSRTL) 


CI  ^    REGEN 


FEE  DIM 


PASS   FLAG  FOR 
TOTAL  REGEN 
OR  JUST 
TEXT 


XTHI 


TEXTHN 


INSRTL 


BUFFER  KEY- 
BOARD LINE   IN 
PC¥0RK,FREDTM, 
LOAD  BLK, 
BUMP  LINE  NO. 
IN  HIT1 


MOVE  P0INTR 
TO   INDICATED 
LINE    (MNLTH) , 
SET  FOR 
INSERT    (MNRPlJ) 


APPL 


BUFFER  KEYBOAID 
LINE   IN  PCW0RI 
FREDTM.LOAD 
BLOCK,   SET   POL 
INSERT  AT  END 
OF  ENTRY    (MNI1E) 


R0UTX  CALL  FOR 
LINE  INSERT 


C2    )    P0PX 


RELESE 
(Await   Input) 


FREDTM 
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LOAD  BLOCK, 
GET  LINE  NO, 
HIT  (MNYNM) 


SET  "MISSED" 
MESSAGE 


(UMISTX)    SEND 
TO   TERMINAL 


SET  LINE  NO, 
INTO  HIT1 


0 


SET  LINE  NO. 
INTO  HIT2    (IF 
WAS   1ST  HIT, 
THEN  HIT1=HIT$ 
IF  WAS   2TO 
NOW  CORRECT) 


SET  HITSNOT  0 


V 

rvELESE 
(Await   Input) 


CALCULATE 
WHICH  FUNCTION 
AND  GO   TO  ROUriNE: 


Dl 
D2 
D3 
■Dk 


APPEND 
DELETE 
CHANGE 
INSERT 
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D2  A  DELETE 


1 


LOAD  BLOCK 


(PERFORM   ^ 
DELETE  (D5)y 


CALL  MNDIX 
WITH  HIT1  AND 
HIT2  LINE 
NUMBERS 


f    RETURN  ) 


0 


CHANGE 


LOAD  BLOCK, 
ENQUE   DPU 


PASS   LINE  NO. 

FROM  HIT1   TO 

DPUK  TO   SEND 

LINE   TO   TERMlJLAi 

(DPUK  IGNORES 

OPERATION   IF, 
HIT1   INVALID) 


/PERFORM         ~*\ 
VDELETE   (D5)  J 


POSITION  P0INTR 

AT  HIT1  LINE    ^MNLTH) 


DU  >     INSERT 


PASS   INSERT 

MODE  KEYBOARD!  ADDR 


GUT2 : 31   (only  the  less   obvious   routines   are   included) 

RGINST   (*U000) 
REGEN  Entry 
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SAVE   THE 
INSTANCE  BLK 


NO, 


RGINST  V 


EXTRACT   CONTRCjL 
ENTRY   FOR 
CURRENT    (1ST) 
INSTANCE. SAVE 
INSTANCE  BLK 
STATUS        


SET  WORK  BLK 
AS    CURRENT 


BIK 


TEST  NAME  AL- 
READY IN  WK 
CONTROL  ENTRY 
WITH  EXTRACTED 
NAME, 


RGJ1SA 


LOAD  NAMED 
4SB  INTO  WORK', 

Iblk  (LDNMBK 
^GINSX.CALL) 


EGINSU 


EKQUE  DPU.ADD 
LINES.  AND  TEX^ 
(DPUM).SEND  TC 
TERMINAL    (DPUC) 


RESET  INSTANCE] 
BLK  AS  CURRENT 
MOVE  P0INTR  TQ 
NEXT  INSTANCE  | 


BLCS 


UNFIX  BOTH 
RETURN   TO   GREi 


(Ignore) 


130 


LDNMHP   (*U633) 
Level  3  Entry 


LDNPC6\ 


DELETE    COKE 
AND  IR  TEMP- 
ORARY  FOR  EACH 
CURRENT 
[PICTURE  BLOCK 


TiCTMmy 


READ  NEW  FCB 
FROM  IR 
( LDNMH2 ) 


LDNPC5 


LDNPCT 


NO   SUCH  PIC- 
TURE,  SO 
INITIALLY  ALLOCATE 
STANDARD  BLKS 

AS   CATlR  WOULD 


FCB  NOW  REPRESENTS 
BLKS   FOR  NEW  PICTURE, 
BUT  BLKS   STILL  ON 
DISK  EVEN  IF  PCB 
ENTRIES   INDICATE 
OTHERWISE    (SOME  BLKS 
MIGHT   STILL  HAVE  BEEN 
IN   CORE  WHEN   FCB  WAS 
SAVED  DURING  SVNMHP). 
SO:    EACH  IN-USE  BLK 
IS  MARKED  NOT-IN- 
CORE   TO  PREVENT 
ILLEGAL   CORE  PURGE 
BY   LDNMBK  IN  SUB- 
SEQUENT PROCESSING 


© 


LDNMHX 


rSET  UP  AND 
2ALL  PIC0PS   TC 
jOAD  EACH  BLK 
<FROM  IR    (PS)/ 


PS     )     PIC0PS 


SET  INTERVAL 
CALL  RETURN 
FOR  WITHIN 
PIC0PS,  ZERO 
BLK  COUNTER 


CALL  INDICATED 
ROUTINE  IN- 
TERNALLY FOR 
EACH  PICTURE 

LK   (0-9) 

LDMNBKjSVNMBk: 

MMBKJL 


Pk  )    PIC0PY 


RESET 
PWRK+1  =   -1 


I 


RLV3 
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LDNMBK  (*UUOO) 

Entry  (Level  3  or  Internal) 


GET  ALLOCATION 
FROM  PCB 


ESTABLISH 
INPUT  BLOCK 
VIA  MNIBA 


SET  DUMMY 
DATA  TO 
INITIALIZE 
BLOCK 


0 


7     J     LDNMBT 


0 


LDNMB2 


SET  SVPRM8= 
(RETURN   CODE 


u 


»  RLV3 


RGINSX 


USE  PWRK  FOR 
ADDRESS,   WAS 
OTHER  INTERNAL 
CALL. RETURN 


RESET  SVPRM6 
AND  SVPRM2 


-0 
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0 
1 


[call  ir  to  read 
{in  named  file 


RESET  AND 

USE  RETURNED 

LENGTH  TO 
ALLOCATE 
PROPER  SPACE 


Routines  NOT  Included 

SVNMBK 
DLNMBK 

SVNBHP 
DLNMHP 

SNDPC 

SNDBLK 

SNDHDR 

SVENMN 
DELNMN 

MENUD 
MENUA 
MENUX 
DIMENN 
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GUT3   (REACT): ^2 

REACT   (*k600) 
Level  2  Entry 


SET  CONSOLE 
VECTOR    (ST0P; 
SET  AUTO- 
SAVE  0FF   (0) 


C0MUN1 


SET  NEW 
DISPLAY  FILE 
(DPUNQ, 
GREGPl) 


SEND  NEW 
DISPLAY  (GREGP2) 


RELESE 
(Await  Input 


A  ))  i    B  J     i    C 

2'?  0  J    DPU   TIMER 


Segment  0  V_^/  Segment  1-9 
Keyboard 


REACL1  (*5000) 
Level  1  Entry 


COPY  RETURN  D\TA 
TO  LEVEL  2  AR3A 


REACT 

© 


A    1  2701  Interrupt 
(C0MIN) 


RESET   TIMER 
(RETIME) 


VVIA  GLMSGA  J 


RELESE 
(Await  Input) 


Timer  Interrupt 


RLV2 
(Exit  to   caller 
on  level  2) 


13k 


& 


P0PY 


CLEAR  DPU  AND 
TIMER   (FREDTM 


RLV2 


B3    ]      C0MJSn 


SET  SEGMENT 
NUMBER  TO  n, 
FREDTM 


SET  2701 
OUTPUT  RECORD: 
Y,   X,   n 


2701  SEND 
(R0UTX) 


RELESE 


B2    }      C0MKB 


EXTRACT  FIRST 
WORDS    FROM  BTJ 


FIVE 
rpER 


COPY  LINE   TO 
PCW0RK, FREDTM 
SEND  TO  2701 
(R0UTX) 


RELESE 


RELESE 
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EXTRACT  SIX 
WORDS  FROM  2701 
BUFFER. CLEAR  270] 
(R0UTX  NO.  U) 


MOVE  IN  NEW 
NAME 


SAVE  ECHO; 
RESET  SEG  1-S 
FILTER  AND 
KEYBRD  FILTER 


0 


A5  )       C0MBTS 


SET  ERASE  AND 
FRAME  BITS 


RELESE 


DO   IMMEDIATE 
DPU  COMMAND 


GREGEN 


RELESE 


) 


».  RELESE 
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FREDTM 


Execute  Command: 

!  !  (EXIT)  -*-  RLV2 

!"  (XCTL  to  GNDR,  level  1  and  2  returns  remain  as  set) 

##  (Load/Send  named  picture)  ■*■   \B6) 

&&  (Load/Send  named  mnemonic)  -*■  (b6) 

C#  (Send  current  picture  as  is  or  renamed)  ^"(b6) 

C&  (Send  current  mnemonic  as  is  or  renamed)  ■*■  (b6) 


0 


SEND  "DONE" 
OR  "ERROR"    TO 
THE  DISPLAY 


REDESE 


DELETE  EACH  P 
BLOCK   (MNDEB) 


[CTURE 


RELESE 


JAVE   CURRENT 

5i  cture  (svm$p) 


5VNMHI 


JES^/dAVE  MNEMON] 

BLK  12    (SVEN^N) 
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© 


C0MTBL 


DISPLAY  THE 
INPUT  BLOCK 
AS 
APPROPRIATE 


RELESE 


0 


C0MNTH 


ALLOCATE  A  BLK  AT  WORK  BLK 
(12)  OR  SPECIFIED  BLK  (0-l(.) 
WITH  MNIBA.   USE  MN2TB  TO 
SET  FIRST  PART  OF  NEW  BLK 


CALL  2701 
(R0UTX3)  TO 
FINISH  INPUTTING 
INTO  NEW  BLOC: 


DEX1   (DEXCHK) ;33 


DEXCHK   (*^000) 
Level   3  Entry 


138 


MATCH  INPUT 
STRING  TO 
LOGON 
DIRECTORY 


\ 

ZES 

y 

,NO 

RETURN  ID, 

RETURN 

PROTECTION 

PASS  1 

_J 

' 

_J 

' 

.PASS  0 

SET  CODE 

INTO 

SUPRM8 

\ 

' 

RLV3 
(Exit   DEX1) 


DEXCHK 


PSIR(IRINIT):3T 
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IRINIT  (*U600) 
GLASP  Entry 
f 


INITIALIZE  IK -CORE- 
POINTERS  (SBUFSZ, 
SBLKDN,  ERRCNT 
DIRCUR) 


IRINI2 


LOCK  ONTO   CPU,    SWAP 
BANKS   0,1   INTO  SLOT 
2. ZERO  BANK  1  AND 
WRITE   ZEROES   INTO 
IR  DISK  DIRECTORY. 


WRITE   LIST   OF  BLOCK 
NUMBERS   INTO   DISK 
FREE   LIST  AND  SET 
UNSORTED  POINTERS 


REQUEST  A  BLOCK: 
SINCE  NO  BLOCKS   IN 
SORTED  LIST,    IR  DOES 
A  SORT!    (VIA  GETBLK) 


FREE   THE  REQUESTED 
BLOCK. RELOAD  BANKS   0, 
1   FROM  SLOT  2. 
RELEASE    CPU 


REFILL   (*U000) 
GETBLK  Entry 


LOCK  ONTO   CPU;READ  IN 
REST  OF  SORTED  LIST 
AND  ADD  TO   IN- CORE   LIST 


ADD  ALL  SORTED  BLOCKS   FROM 
IN- CORE   LIST  TO   DISK  UN- 
SORTED  LIST  VIA  FREBUF 


SWAP  BANKS   0,   1   INTO  SLOT 
1.      READ  UNSORTED  LIST 
INTO  BANK  0. 


SORT   LIST  INTO   "POCKETS" 
(M0D  60)    INTO  BANK   1. 
COLLECT  AND  WRITE  ONTO 
DISK  SORTED  LIST 


RELOAD  BANKS   0,   1   FROM 
SLOT  1.      RESET  BLOCK 
POINTERS 


Exit   to   GETBLK 


Exit    to   GLASP 
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